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Введение 


Технологии баз данных являются основой, на которой держатся 
многие компьютерные науки, поэтому уверенные знания в данной облас- 
ти могут служить залогом успешного освоения дисциплин профессио- 
нального цикла. 

Содержание пособия полностью соответствует стандартной про- 
грамме курса «Базы данных» ГОС ВПО, используемая терминология со- 
гласуется с известными, много раз переиздававшимися фундаментальны- 
ми работами по базам данных. Основная цель автора пособия - изложить 
лаконично и систематизированно материал, почерпнутый из большого 
количества источников, дополнить его собственными примерами и сведе- 
ниями о современном состоянии некоторых проблем. 

Пособие содержит пять глав. В первой определяются основные по- 
нятия и дается неформальное введение в системы баз данных. Вторая 
глава содержит лаконичное, но достаточно строгое описание реляцион- 
ной модели данных, третья глава посвящена вопросам проектирования 
реляционных структур. Четвертая глава, самая объемная, содержит сис- 
тематическое описание языка 501. и одного из его процедурных расши- 
рений. Данный материал невозможно изложить чисто абстрактно, поэто- 
му пособие содержит большое количество примеров, которые помогут 
понять логику разработки запросов и программного кода, хранимого в 
базе данных. Все примеры ориентированы на одну из самых распростра- 
ненных коммерческих СУБД Огасе. Наконец, пятая глава посвящена во- 
просам грамотного использования всех возможностей современных 
СУБД, здесь тоже в качества примера СУБД используется Огасіе. 

В качестве дополнения к пособию следует использовать методиче- 
ские указания к лабораторным работам и курсовому проектированию, 
электронный УМК по базам данных и дистанционный практикум по язы- 
ку ЗОГ на основе автоматизированной проверяющей системы. 

Пособие предназначено для студентов специальностей 220201 — 
«Управление и информатика в технических системах» и 230105 — «Про- 
граммное обеспечение вычислительной техники и автоматизированных 
систем», но может использоваться студентами любых специальностей, 
которые изучают предметы «Базы данных», «Программирование баз дан- 
НЫХ», «Базы данных и экспертные системы» и другие родственные дис- 
ЦИПЛИНЫ. 


1. Основные понятия 


Цель изучения данной главы — овладеть терминологией и понятий- 
ным аппаратом дисциплины для эффективного изучения остальных глав 
пособия. 

После изучения главы вы будете: 

е иметь общие представления о базах данных, СУБД и информацион- 
ных системах; 

е знать основные архитектуры информационных систем, уметь обосно- 
вать выбор архитектуры для решения конкретной задачи 

® знать основные модели данных, иметь неформальные представления 

о реляционной модели 
® знать принципы построения информационных систем 
® иметь представления об основных СУБД, имеющихся на рынке ПО, 

уметь грамотно выбрать СУБД в процессе разработки информацион- 
ной системы 


1.1. Терминология, базовые принципы 


1.1.1. Понятие базы данных, СУБД и 
информационной системы 


База данных – совокупность структурированных, взаимосвязанных, 
динамически обновляемых данных определенной предметной области. 
Предметная область – часть реального мира (например, промышленное 
предприятие, учебное заведение, организация, работающая в сфере услуг 
и т.д.), подлежащая изучению с целью ее автоматизации. Если предмет- 
ная область уже автоматизирована, хотя бы частично, но требуется про- 
вести мероприятия по реорганизации существующей автоматизированной 
системы, иногда применяют термин проблемная область. 

Любая предметная область несет в себе огромное количество ин- 
формации, часть которой, полезную с точки зрения персонала, можно 
четко выделить, структурировать и сохранить на электронном носителе с 
целью последующего эффективного поиска и обработки. Структуриро- 
ванная информация предметной области, хранимая на электронном носи- 
теле, представляет собой данные. 

Некоторую часть информации предметной области можно сформу- 
лировать в виде бизнес-правил — формальных правил, которые учитыва- 
ются при определении связей между элементами данных. Так формирует- 
ся база данных, которую можно считать информационной моделью пред- 
метной области. Схематически это показано на рис.1.1. 


Предметная область База данных 


информация 
Л 


х, сами между 
ланными 


бизнес-правила 


Рис. 1.1. Предметная область и база данных 


По степени структурированности информации различают докумен- 
то-ориентированные и фактографические базы данных. Документо- 
ориентированные базы содержат слабоструктурированные данные, обыч- 
но представленные в виде текстовых документов различных форматов. 
Фактографические базы данных содержат четко структурированную со- 
вокупность данных, основанную на известных в программировании 
структурах данных. 

Способ организации данных и связей в фактографической базе дан- 
ных называют моделью данных. Более строгое определение модели дан- 
ных содержится в разделе 1.3. 

База данных (БД) вместе с поддерживающим ее программным обес- 
печением (ПО) образует информационную систему (ИС). Коротко это 
можно записать в виде простой формулы БД + ПО= ИС. 

Некоторые авторы понимают информационную систему более широко, 

включая в это понятие еще технические средства и обслуживающий пер- 

сонал. Иногда встречается и более узкая трактовка информационной сис- 
темы как совокупность данных и набор программных средств для реше- 
ния конкретной прикладной задачи, например, задачи бухгалтерского или 
складского учета. 
Классификация ИС 
По назначению можно выделить несколько классов ИС: 

® ИПС - информационно-поисковые системы. Служат для эффектив- 
ного поиска информации (примером являются поисковые серверы 
Интернет); 

• УИС (ЭИС) — управляющие (экономические) информационные сис- 
темы. Такие системы предназначены для автоматизации отдельных 
функций управления каким-либо экономическим объектом (подразде- 
лением, предприятием, корпорацией), поэтому являются важнейшей 
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частью АСУП (автоматизированной системы управления предприяти- 
ем). УИС, как правило, содержат подсистему учета данных, отражаю- 
щих все основные факты деятельности предприятия, и подсистему 
анализа накопленных данных, которая позволяет руководству пред- 
приятия принять грамотное управленческое решение. Такие системы 
называются системами поддержки принятия решений (СППР). 
® ЭС — экспертные системы. Способны на самостоятельное принятие 
решений, т к. имеют в своем составе базу знаний, позволяющую по- 
лучать новые знания на основе уже имеющихся. 
По предметной области ИС можно разделить на системы, исполь- 
зуемые в производстве, образовании, здравоохранении, науке, военном 
деле, социальной сфере, торговле и других отраслях. 


Состав ИС, персонал, взаимодействующий с системой 

Программное обеспечение (ПО) для поддержки базы данных неод- 
нородно. Обычно все ПО подразделяют на базовое и прикладное (ПрПО). 

Базовое ПО включает операционную систему (ОС), которая непо- 
средственно осуществляет доступ к данным на диске, а также специаль- 
ный комплекс дополнительных программных средств, которые получили 
название системы управления базами данных. Можно рассматривать 
СУБД как некоторую надстройку над ОС, которая значительно расширяет 
стандартные возможности ОС по управлению данными. 

ПРПО включает программы (приложения), специфичные для кон- 
кретной предметной области, которые решают все прикладные задачи, 
необходимые пользователям системы. Все прикладные программы взаи- 
модействуют с базой данных только через СУБД. Взаимодействие про- 
граммных компонентов информационной системы, а также круга лиц, 
взаимодействующих с системой, показано на рис. 1.2. 
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пользователи 
(представители 
предметной области) 


квалифици рованные 
пользователи 


разработчики 


Администратор БД 


Рис. 1.2. Состав ИС, персонал, взаимодействующий с ИС 


Здесь под обычными пользователями понимаются специалисты 
предметной области, которые используют ИС для автоматизации опреде- 
ленной части своей деятельности (иногда их называют конечными пользо- 
вателями). Они взаимодействуют с БД только через ПрПО. При установ- 
ке нового ПрПО пользователи проходят курс обучения по его правильно- 
му использованию. 

Выделим (чисто условно) часть пользователей в группу, которую на- 
зовем «продвинутыми» (квалифицированными) пользователями. Пред- 
ставители этой группы имеют некоторое образование в области компью- 
терных технологий и способны обращаться напрямую к функциям СУБД, 
если им предоставлены такие права. Для этой цели в СУБД есть различ- 
ные средства взаимодействия с пользователями, основным из которых 
является стандартизированный язык запросов к базе данных 801, (под- 
робное описание с примерами содержится в главе 4). Однако основную 
часть своей работы любые пользователи предпочитают выполнять с 
удобством, которое им предоставляет ПрПО. 

Для успешной работы пользователей системы группа разработчиков 
подготовила ПрПО и осуществляет его сопровождение. Представители 
этой группы имеют основное образование в области программирования и 
компьютерных технологий, они имеют знания в области доступа к базам 
данных и навыки работы с инструментальными средствами разработки 
приложений баз данных. Отдельно выделим специалистов в области про- 
ектирования структур баз данных. Вопросы проектирования БД подробно 
обсуждаются в главе 3. 

Наконец, немаловажную роль в обеспечении бесперебойного функ- 
ционирования системы играет администратор базы данных (АБД, это 
может быть один человек или группа лиц). АБД несет ответственность за 
безопасность и целостность всех данных и осуществляет такие функции, 
как разграничение доступа пользователей и аудит их действий, регуляр- 
ное резервное копирование данных и восстановление БД в случае сбоев, 
обеспечение приемлемой производительности системы, целостности дан- 
ных и т.д. Этим вопросам посвящена глава 5. 


1.1.2. База данных и СУБД 


Современные базы данных самодостаточны и относительно незави- 
симы от прикладного ПО (на рис. 1.2. видно, что некоторые пользователи 
работают с базой данных непосредственно через СУБД, минуя слой 
ПрПО). Такая возможность достигается за счет того, что в современной 
базе данных хранятся не только сами данные, но и их описание (метадан- 
ные, т. е. данные над данными), а также некоторый программный код для 
обработки данных (рис. 1.3). 


Часть БД, в которой хранятся 
данные, получила название словаря дан- 
ных (СД). Словарь данных в том или 
ином виде присутствует в любой базе 
данных, независимо от используемой 
модели данных. Для каждого элемента 
данных в СД хранится его уникальное 
имя, тип, размер и некоторые другие 
свойства. Интересно, что в реляционных 
базах данных все элементы словаря дан- 
ных хранятся в таблицах, также как и 
данные, а для манипулирования элементами словаря используются те же 
самые реляционные операции, что и для данных. 

Дополнительной возможностью, которая поддерживается большин- 
ством ведущих производителей СУБД, является хранение программного 
кода для обработки данных непосредственно в базе данных вместе с дан- 
ными и метаданными. Более подробная информация о составе базы дан- 
ных и хранимом програмном коде содержится в главе 4. 

СУБД – комплекс программных и языковых средств для создания, 
ведения и коллективного использования базы данных. В таблице 1.1 при- 
веден список основных функций СУБД, а также языковые и программные 
средства СУБД, необходимые для реализации каждой функции. 


метаданные - 
описание данных 


данные 


хранимый код 


Рис. 1.3. Состав БД 


Таблица 1.1 
Функции СУБД и средства для их реализации 
Функции СУБД: Языковые средства Программные средства 

1) создание БД и модифи- | Язык ПИТ, (даа 4ейп1- Процессор ОРІ, 
кация метаданных боп 1апопасе) в перево- 

де ЯОД (язык опреде- 

ления данных) 
2) заполнение БД и об- Язык ОМІ, (даќа тат- Оптимизатор 
новление данных ршайоп Іапопаое) в запросов (Опегу Орііх- 
3) Извлечение данных переводе ЯМД (язык ег)— разработка опти- 


(выборка) 


манипулирования дан- 
ными) 


мального плана исполне- 
ния запроса пользовате- 
ля, процессор базы дан- 
ных (ОВ Епеше)— ис- 
полнение запроса по 
плану 


4) обработка данных 


Средства разработки 
хранимого кода - язык 
высокого уровня, до- 
полненный командами 
ОМЕ или встроенный 
язык СУБД 
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Компилятор языка про- 
граммирования, процес- 
сор базы данных 


5) обеспечение целостно- 
сти данных 


Правила поддержки 
целостности (ограниче- 
ния) в языке ОПГ, воз- 
можность встраивать 
поддержку целостности 
в хранимый код 


Окончание табл. 1.1 
Процессор базы данных, 
встроенные средства 
проверки целостности 


6) обеспечение безопас- 
ности данных 
(разграничение доступа 
пользователей и аудит их 
действий) 


Система команд управ- 
ления доступом к дан- 
НЫМ 


Подсистема безопасно- 
сти 


7) организация коллек- Система команд для Монитор транзакций, 
тивного доступа к дан- поддержки транзакций | подсистема блокировок 
ным (параллелизм) и управления блоки- 

ровками 


Утилиты резервного 
копирования, встроенные 
средства восстановления 


БД 


8) резервное копирование 
и восстановление 


1.1.3. Принципы построения информационных 
систем 


Обобщим материал предыдущих разделов, выделив основные прин- 
ципы. Все принципы очень тесно взаимосвязаны и вытекают одно из дру- 
гого, поэтому приведенное ниже разделение будем считать условным. 

1. Принцип интегрированности 

Принцип состоит в том, что существует одна единая интегрирован- 

ная БД для всей предметной области (рис.1.4), которая совместно исполь- 
зуется персоналом, при этом одновременно может быть запущено мно- 
жество приложений (на рисунке ПІ, П2 и т.д.) с различной функцио- 
нальностью. 
Так, все подразделения одного предприятия исполняют различные функ- 
ции, но имеют очень тесные информационные связи, поэтому автономная 
автоматизация каждого подразделения на основе отдельных БД (так на- 
зываемая «кусочная» автоматизация предприятия) приводит к дублиро- 
ванию данных, избыточным операциям ручного ввода в различных под- 
разделениях, что может привести к нестыковкам данных вследствие 
ошибок ввода и другим негативным последствиям. 
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а 


Рис. 1.4. Интегрированная информационная система 


В противоположность «кусочной» автоматизации, автоматизация на 
основе интегрированной информационной системы имеет ряд очень су- 
щественных положительных моментов. 

• В интегрированной системе может быть достигнута минимальная 
избыточность (отсутствие дублирования) данных. Этот принцип 
обычно формулируется так: «Каждый факт - в одном месте». В реля- 
ционной базе данных некоторая избыточность вносится только для 
установления связей между таблицами с помощью одинаковых 
столбцов. Более подробная информация об этом содержится в главе 3 
«Проектирование базы данных». 

• В интегрированной системе легче добиться непротиворечивости (це- 
лостности) данных, т.к. ввиду отсутствия дублирования данных нет и 
их нестыковок. Имеется возможность контролировать целостность 
данных встроенными средствами СУБД, более подробная информа- 
ция об этом содержится в разделе 2.1. 

• В интегрированной системе удобнее выполнять поиск и обработку 
данных, можно выполнять любые виды обработки и анализа данных. 

е Для интегрированной ИС проще решается проблема резервного ко- 
пирования данных и восстановления поврежденных данных, так как 
эту задачу можно возложить на одного человека (АБД), который бу- 
дет нести персональную ответственность за сохранность всех корпо- 
ративных данных. 

Следует отметить, что предприятия, имеющие территориально рас- 
пределенную структуру, обычно используют так называемые распреде- 
ленные базы данных, в которых отдельные элементы базы данных физи- 
чески располагаются в различных узлах корпоративной сети. Тем не ме- 
нее, распределенные базы данных проектируются таким образом, чтобы 
не нарушать принципа интегрированности. 


12 


2. Принцип независимости прикладного программного обеспечения 
от способа организации данных. 

Между данными и прикладным программным обеспечением ИС на- 
ходятся, как минимум, два слоя базового программного обеспечения – опе- 
рационная система и СУБД, которые берут на себя все низкоуровневые 
функции управления данными. Поэтому база данных может функциониро- 
вать и вообще без ПрПО, а одно и то же ПрПО может взаимодействовать с 
базами данных, имеющими различную физическую организацию. 

Различают следующие уровни независимости: 

а) логическая независимость — можно вносить некоторые изменения 
в структуру уже заполненной базы данных без коренной переделки при- 
кладного программного обеспечения, например, можно добавить новые 
столбцы в уже заполненную таблицу базы данных, при этом все прило- 
жения не потеряют работоспособности, однако при удалении столбцов, а 
тем более таблиц некоторые приложения работать не смогут; 

б) физическая независимость — может быть изменен физический 
формат хранения данных, т.е. переход на новую СУБД или новую версию 
СУБД, без коренной переделки прикладного программного обеспечения 
(Прпо о физическом формате хранения данных вообще ничего «не зна- 
ет», поскольку работает с данными на логическом уровне). 


3. Принципы масштабируемости и переносимости 

Данные принципы вытекают из принципа независимости данных и 
ПРПО. Принцип масштабируемости следует рассматривать в трех аспектах: 

а) возможность неограниченного наращивания размеров БД; 

6) неограниченное увеличение количества пользователей; 

в) неограниченное увеличение количества приложений. 

В определенный момент времени сушествующее базовое ПО пере- 
станет удовлетворять требованиям эффективного управления возросшим 
количеством данных, или не сможет обеспечить приемлемую скорость 
работы для увеличившегося количества пользователей, поэтому возник- 
нет необходимость перенести данные на новую платформу, что должно 
быть выполнено без потери информации и коренной переделки ПрПО. 
Это свойство ИС называется переносимостью. 

Концепция открытых систем предлагает в качестве механизма во- 
площения в жизнь перечисленных выше принципов использовать обще- 
признанные международные стандарты, регламентирующие все аспек- 
ты функционирования информационной системы. В настоящее время 
имеющиеся стандарты открытых систем позволяют разворачивать интег- 
рированные гетерогенные информационные системы, основанные на ис- 
пользовании разнородного программного обеспечения, обеспечивать их 
масштабируемость и переносимость. 

Далее рассмотрим архитектуры информационных систем подробнее. 
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1.2. Архитектуры информационных систем 


1.2.1. Понятие архитектуры информационной 
системы 


Архитектура – это совокупность существенных решений об органи- 
зации ИС. Обычно в понятие архитектуры входят решения об основных 
аппаратных и программных составляющих системы, их функциональном 
назначении и организации связей между ними. 

Выбор архитектуры ИС влияет на следующие характеристики: 

1. Производительность ИС – количество работ, выполняемых в ИС за 
единицу времени. 

2. Время реакции системы на запросы пользователя (время отклика сис- 
темы). 

3. Надёжность — способность к безотказному функционированию в те- 
чение определенного периода времени. 


Локальные ИС, которые располагаются целиком на одном компью- 
тере и предназначены для работы только одного пользователя, сейчас 
встречаются крайне редко. В дальнейшем речь пойдет о распределенных 
ИС, которые функционируют в сети и предназначены для многопользова- 
тельской (коллективной) работы. 

Обычно база данных целиком хранится в одном узле сети, поддер- 
живается одним сервером и доступна для всех пользователей локальной 
сети, называемых клиентами. Такая база данных называется централизо- 
ванной. Распределенные базы данных, в которых БД распределена по не- 
скольким узлам сети, обычно используются в организациях, содержащих 
территориально удаленные подразделения. 

Сервер, как правило, — самый мощный и самый надежный компью- 
тер. Он обязательно подключается через источник бесперебойного пита- 
ния, в нем предусматриваются системы двойного или даже тройного дуб- 
лирования. В зависимости от распределения функций обработки данных 
между сервером и клиентами различают две основных архитектуры – 
«файл-сервер» и «клиент-сервер». Возможны разновидности этих двух 
вариантов. 


1.2.2. Архитектура «файл-сервер» 


Для предприятий малого бизнеса возможна организация информацион- 
ной системы на базе архитектуры "файл-сервер" с использованием СУБД 
Ассеѕѕ, ЕохРто (\15иа1 ЕохРго), Рагадох и ряда других. Если количество 
пользователей системы не велико, подобное решение оптимально. 
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В архитектуре файл-сервер вся обработка данных выполняется на клиент- 
ских компьютерах, сервер служит в качестве хранилища данных (рис. 1.5). 


ааа Синхронизация БД 


= ывапыин = | Временная копи У. 
У базы данных  -) 
Синхронизация СУБД 


БД и 
копий 


аа а а БЕ 

Временная копия 

[8 базы данных 
— = = = 


Рис.1.5. Архитектура файл-сервер 


Копии базы данных передаются для обработки на клиентские ком- 
пьютеры, при этом постоянно выполняется синхронизация основной базы 
данных с ее копиями в случае их обновления. 

Недостаток архитектуры файл-сервер — большая нагрузка на сеть и 
клиентские компьютеры, поскольку на всех клиентских компьютерах 
должна быть установлена копия СУБД, которая выполняет все необходи- 
мые функции по обработке данных, при этом все изменения в копиях обя- 
зательно передаются по сети в основную базу данных, существенно по- 
вышая сетевой трафик. 

Преимущество состоит в том, что не требуется мощный сервер. Та- 
кую архитектуру можно реализовать даже в одноранговой сети без выде- 
ленного сервера, необходимо только выделить один из компьютеров в 
качестве хранилища общей базы данных. 

Количество пользователей системы в архитектуре файл-сервер 
обычно не должно превышать 10-15, в противном случае пользователи 
будут ощущать замедление работы. Данное обстоятельство служит нару- 
шением принципа масштабируемости (раздел 1.1), поэтому по мере роста 
количества пользователей ИС (допустим, произошло существенное рас- 
ширение бизнеса) приходится выполнять переход от файл-серверной к 
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клиент-серверной архитектуре. При разработке файл-серверной системы 
всегда нужно учитывать возможность такого перехода в буду щем. 


1.2.3. Архитектура «клиент-сервер» 


Применительно к информационным системам архитектура «клиент- 
сервер» интересна и актуальна главным образом потому, что обеспечива- 
ет простое и относительно дешевое решение проблемы коллективного 
(многопользовательского) доступа к базам данных в локальной или гло- 
бальной сети. 

Информационная система архитектуры «клиент-сервер» разбивается 
на две части, которые могут выполняться в разных узлах сети, - клиент- 
скую и серверную части. На серверную часть возлагаются функции хра- 
нения и значительной части обработки данных, на клиентскую — функции 
взаимодействия с пользователем и, частично, обработки данных, полу- 
ченных с сервера (рис. 1.6). 


сервер клиенты 


Клиентская 
часть сервера 


База 
данных 


501 - 


сервер БОІ -запрос / ответ Клиентская 
часть сервера 


| 
| Прпо | 


Рис. 1.6. Архитектура «клиент-сервер» 


Следует заметить, что обе части системы (серверная и клиентская) 
могут располагаться и на одном компьютере, такой вариант можно при- 
менять в процессе отладки клиент-серверной системы. 

Для того, чтобы прикладная программа, выполняющаяся на клиент- 
ском компьютере, могла запросить услугу у сервера, требуется некоторый 
интерфейсный программный слой, поддерживающий взаимодействие 
сервера с клиентами. Прикладное ПО или конечный пользователь взаи- 
модействуют с клиентской частью системы. Клиентская часть системы 
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при потребности обращается по сети к серверной части. Интерфейс сер- 
верной части определен и фиксирован. 

В современных информационных системах таким интерфейсом, как 
правило, является язык ЗОГ, т.е. сервер принимает от клиентской части 
ЗОГ.-запрос и выполняет необходимые операции в базе данных, после 
чего возвращает ответ клиенту. По сути, язык 501, представляет собой 
стандарт интерфейса СУБД в открытых системах (концепция открытых 
систем затрагивалась в предыдущем разделе). 

В системе «клиент-сервер» возможно создание новых клиентских 
частей уже существующей системы, причем максимальное количество 
одновременно работающих с общей БД клиентов несравнимо больше, 
чем в файл-серверной архитектуре, т.е. система клиент-сервер является 
более масштабируемой. Это объясняется тем, что сетевой трафик в кли- 
ент-серверной системе невысок (от клиента передаются только тексты 
запросов, от сервера — уже отобранные данные, а не вся база данных, как 
в архитектуре файл-сервер). 

Термин «сервер баз данных» обычно используют для обозначения 
всей СУБД, основанной на архитектуре "клиент-сервер", включая сервер- 
ную и клиентскую части. Собирательное название ЗОГ.-сервер относится 
ко всем серверам баз данных, основанных на использовании языка $01. 

В настоящее время имеется несколько широко распространенных 
коммерческих ЗОГ-серверов — Ога е, ОВ-2, М5 801. Ѕегуег, Ѕубаѕе, ш- 
Ғогтіх, Пиефазе и свободно распространяемые серверы с открытым ис- 
ходным кодом РоѕіОтеѕ (Розфтее ОГ), МузОГ, ЕтеВіга (свободно рас- 
пространяемый вариант сервера Пие фазе). Приведенный список далеко 
не полон. 

ЗОГ.-серверы обладают преимуществами и недостатками. Очевидное 
прсимущсство - стандартность интерфейса. В пределе, хотя на практикс 
это пока не совсем так, клиентские части могли бы работать с любым 
ЗОГ.-сервером вне зависимости от того, кто его произвел. Иными слова- 
ми, прикладное программное обеспечение на стороне клиента легко на- 
страивается на взаимодействие с любым новым ЗОГ.-сервером. 

Недостаток — большая нагрузка на сервер, который должен отраба- 
тывать запросы всех клиентов, и малая нагрузка на клиентскую часть. По 
мере роста количества одновременно работающих пользователей сервер 
часто становится узким местом всей системы и возникает необходимость 
его разгрузки. Для этого существуют два пути. 
® Если клиентские компьютеры обладают достаточной мощностью, то 

можно возложить на них больше функций обработки данных, разгру- 

зив сервер. 
® В случае применения маломощных клиентских компьютеров (а это 
более типичная ситуация), применяют многозвенную (многоуровне- 
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вую) архитектуру «клиент-сервер», выделив промежуточные дополни- 
тельные слои программного обеспечения между клиентом и сервером. 


1.2.4. Многозвенные архитектуры 


Многозвенные (многоуровневые) архитектуры позволяют обеспе- 
чить более оптимальную загрузку технических средств. чем классическая 
двухзвенная архитектура, и обеспечивают возможность плавного мас- 
штабирования информационной системы. Наиболее распространенным 
случаем является трехзвенная архитектура, в которой в качестве проме- 
жуточного слоя программного обеспечения между сервером и клиентом 
используется сервер приложений (рис. 1.7). Сервер приложений берет на 
себя существенную часть обработки данных, позволяя разгрузить и сер- 
верную, и клиентскую части. 


База 
данных 


Тонкие клиенты 


Сервер А А 
ъ| приложений 


ЅОГ-сервер 


Рис. 1.7. Трехзвенная архитектура 


В трехзвенной архитектуре часто используется так называемый тон- 
кий клиент (т сііепі), который вообще не выполняет никаких функций 
обработки данных, а только обеспечивает представление данных и взаи- 
модействие с пользователем. В отличие от этого, клиента двухзвенной 
системы обычно называют толстым клиентом (аі сііепі). 

В качестве примера широко используемых ИС трехзвенной архитек- 
туры можно привести любую конфигурацию на базе платформы разра- 
ботки 1С:Предприятие версии 8 (более ранняя версия 7.7 этой платформы 
использует либо файл-серверную, либо двухзвенную архитектуру клиент- 
сервер). В качестве ЗОГ-сервера системы ІС могут использовать М5 
ЅОГ-сервер, либо свободно распространяемую РоѕіОтеѕ, в качестве сер- 
вера приложений – сервер ІС. 
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1.2.5. Информационные системы на основе 
меб-архитектуры 
Достижения в области технологий Іпіегпеі привели к широкому рас- 


пространению еще одной разновидности клиент-серверной архитектуры, 
которая получила название үеб-архитектуры (рис.1.8) 


База 
данных 


Клиенты 


\МЕВ - браузеј 
| 


МУЕВ — 
сервер 


ѕзаг- 
сервер 


< МЕВ - браузер 
Рис.1.8. И’еЬ-архитектура 


В меб-архитектуре обязательным является наличие еще одного до- 
полнительного компонента — үер-сервера, на котором устанавливается 
прикладное программное обеспечение, обеспечивающее всю необходи- 
мую функциональность ИС. В качестве такого сервера может использо- 
ваться Іпќіегпеё Іпѓогтайоп Ѕегуег (П5) фирмы Місгоѕоё или свободно рас- 
пространяемый М№еб-сервер Арасће. 

На клиентской стороне требуется только браузер (например, Пщегпей 
ЕхрІогег) для отображения Ви-страниц, принимаемых со стороны үеб- 
сервера, и взаимодействия с пользователем. 

В современных ИС между ЗОГ-сервером и М№еБ-сервером часто на- 
ходится еще одно звено — сервер приложений, который берет на себя 
большую часть обработки данных и позволяет одновременно разгрузить и 
ЗОГ-сервер, и №еб-сервер. В качестве примера подобной архитектуры 
можно привести информационные системы на платформе Ј2ЕЕ. 

Преимуществом уеб-архитектуры является удобство администриро- 
вания ИС (на клиенте вообще не требуется устанавливать никакого спе- 
циального программного обеспечения), возможность доступа пользовате- 
лей к данным как с любого компьютера локальной сети, так и удаленно 
через Пщегпе. 

Широкое применение эта архитектура находит в системах дистан- 
ционного образования, системах электронной торговли, социальных 
сетях и других системах с массовым доступом пользователей, возмож- 
но, удаленным. 
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Недостатком является повышенная угроза безопасности системы, 
подключенной к глобальной сети Интернет, что усложняет задачу обес- 
печения безопасности и требует тщательно продуманной системы разгра- 
ничения доступа пользователей, применения тех или иных методов шиф- 
рования данных. 

В системах, содержащих конфиденциальные данные или данные, яв- 
ляющиеся коммерческой тайной предприятия, үер-архитектура исполь- 
зуется редко, при этом обычно устанавливается внутренний У/еб-сервер, 
не подключенный к глобальной сети. 


1.2.6. Информационные системы, функционирующие 
в терминальном режиме 


Если предприятие имеет мощный сервер и довольно маломощные 
клиентские компьютеры, оно может развернуть информационную систе- 
му в терминальном режиме. При таком способе организации весь про- 
граммный код как серверной, так и клиентской части исполняется на сер- 
вере, а на терминалы передается лишь изображение, которое должно быть 
отображено на экране монитора (рис. 1.8). Все данные, введенные с тер- 
минала, немедленно передаются для обработки на сервер. 

Роль терминалов с успехом могут исполнять обычные персональные 
компьютеры, для этого на каждом из них должна быть запущена специаль- 
ная программа – эмулятор терминала. В таком режиме может быть развер- 
нута и файл-серверная, и клиент-серверная архитектура, в любом случае на 
сервере должно быть запущено столько копий клиентского программного 
обеспечения, сколько терминалов подключено к серверу (рис. 1.9). 


Мощный сервер 


Клиентское 
данных 
Серверное Терминал 


по 
Рис. 1.9. Терминальный вариант развертывания ИС 
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Преимущества такого варианта налицо — простота и удобство адми- 
нистрирования (все ПО сосредоточено на одном сервере), повышенная 
безопасность, самые низкие требования к клиентским компьютерам. 
Однако требования к серверу, на котором сосредоточено функционирова- 
ние все системы, очень высокие, а выход его из строя даже на короткое 
время может расцениваться как катастрофа, поскольку вся система стано- 
вится неработоспособной. 


1.3. Модели данных 


Модель данных в общем виде можно представить в виде трех со- 
ставляющих: 
® логическая структура данных (в первую очередь, способ органи- 
зации связей между элементами данных): 
• набор допустимых операций по манипулированию данными для 
принятой логической структуры; 
® правила поддержки целостности (непротиворечивости) данных 
для принятой логической структуры. 

Теоретические основы баз данных и языков программирования до- 
вольно долго развивались параллельно, поэтому концепция абстрактного 
типа данных (АТД), которая давно и прочно утвердилась в программиро- 
вании, в базах данных также довольно долго и устойчиво развивается в 
терминах модели данных. Тем не менее, можно считать понятия «модель 
данных» и «абстрактный тип данных» очень близкими по смыслу. Изучая 
предмет «Базы данных», будем придерживаться его терминологии. 


1.3.1. Сравнительная характеристика моделей 
данных 


К основным моделям данных относят следующие: 

иерархическая (на основе деревьев), 

сетевая (на основе многосвязных структур графов), 
реляционная (на основе таблиц), 

постреляционная (таблицы с возможностью вложения одних таб- 
лиц в другие), 

е объектно-ориентированная (на основе принципов объектно- 

ориентированного программирования). 

Иерархическую и сетевую модель в настоящее время следует при- 
знать интересными лишь в историко-теоретическом плане, поскольку 
первые СУБД, появившиеся в 60-е - 70-е годы, поддерживали именно эти 
модели. Безусловно, многие полезные идеи, отработанные в рамках ие- 
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рархических и сетевых СУБД, находят применение и в современных сис- 
темах, основанных на реляционной модели и ее развитии в виде постре- 
ляционной и объектно-ориентированной модели. 

Все приведенные выше модели данных основаны на структурах, хо- 
рошо известных в программировании, однако их применение для органи- 
зации баз данных имеет определенную специфику, поэтому кратко оста- 
новимся на особенностях каждой из моделей. 


1. Иерархическая модель данных 


В СУБД иерархического типа вся информация представлена в виде 
деревьев, узлами которых являются записи (например, записи о подраз- 
делениях предприятия, сотрудниках подразделений и их детях образуют 
дерево). Корневая запись каждого экземпляра дерева (в нашем случае 
запись о подразделении) обязательно должна содержать ключ с уникаль- 
ным значением. Ключи некорневых записей должны иметь уникальное 
значение только в рамках данного экземпляра дерева. Каждая запись 
идентифицируется полным сцепленным ключом - совокупностью ключей 
всех записей, начиная от корневой, по иерархическому пути. 

Каждый экземпляр дерева называется групповым отношением, кор- 
невая запись называется владельцем группового отношения, а все дочер- 
ние записи — членами группового отношения. 

Говорят, что иерархическая модель реализует отношение «один-ко- 
многим» (опе-ю-тапу) между исходной и дочерней записью, поскольку 
каждому экземпляру исходной записи соответствует несколько экземпля- 
ров дочерних записей. Такое отношение обозначается как 1:М или 1:№. 

Например, в каждом подразделении предприятия может работать не- 
сколько («много») сотрудников, но каждый сотрудник принадлежит 
только одному подразделению. 

В иерархических БД поддерживается целостность связей между вла- 
дельцами и членами группового отношения (никакой потомок не может 
существовать без своего предка). 

Недостатки иерархических БД: 

Кроме отношения «один-ко-многим» (1:М), довольно распростра- 
ненным на практике является отношение «многие-ко-многим» (М:М, 
шапу-ю-тапу). Например, в приведенном примере с подразделениями и 
их сотрудниками бизнес-правила предприятия могут допускать возмож- 
ность работы сотрудника и в нескольких подразделениях одновременно. 
Такого сотрудника придется включить в экземпляры деревьев для всех 
подразделений, в которых он работает. То же самое можно сказать и об 
отношении «сотрудники - дети», поскольку возможна ситуация, когда оба 
родителя ребенка работают на одном предприятии и даже в одном под- 
разделении. Таким образом, возникает дублирование информации. 
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Запросы на поиск информации в иерархической базе данных выпол- 
няются по-разному. Поиск, выполняющийся в направлении от корневой к 
дочерним записям (например, получить сведения обо всех сотрудниках 
бухгалтерии), выполняется очень эффективно, но поиск в обратном на- 
правлении (например, выяснить, в каком подразделении работает роди- 
тель Пети Иванова), наоборот, выполняется крайне медленно. 

В настоящее время иерархическая модель используется редко, в ос- 
новном, для отдельных специальных применений. Например, реестр \/т- 
40% представляет собой иерархическую базу данных. 

Широко распространенных коммерческих или свободно распростра- 
няемых СУБД, поддерживающих иерархическую модель, в настоящее 
время нет. 


2. Сетевая модель данных 


Сетевая модель данных определяется в тех же терминах, что и ие- 
рархическая. Она состоит из множества записей, которые могут быть 
владельцами или членами групповых отношений. Связь между записью- 
владельцем и записью-членом также имеет вид 1:М. 

Основное различие этих моделей состоит в том, что в сетевой моде- 
ли запись может быть членом более чем одного группового отношения. 
Продолжая пример с подразделениями и сотрудниками, в сетевой модели 
можно включить запись о сотрудникс в групповые отношения для раз- 
личных подразделений. Таким образом, в сетевой модели данных, в отли- 
чие от иерархической, дублирование информации отсутствует. 

Согласно этой модели, каждое групповое отношение именуется и 
проводится различие между его типом и экземпляром. Тип группового 
отношения задается его именем и определяет свойства, общие для всех 
экземпляров данного типа. Экземпляр группового отношения представля- 
ется записью-владельцем и множеством (возможно пустым) подчиненных 
записей. 

Отсутствие дублирования информации, безусловно, является самым 
главным достоинством сетевой модели данных. Недостатком сетевой 
модели является ее чрезмерная сложность, что в период распространения 
сетевых СУБД приводило к большим проблемам в администрировании 
сетевых баз данных. Например, проблема восстановления поврежденных 
или утраченных данных решалась ценой огромных усилий. Некоторые 
запросы в сетевых базах, как и в иерархических, выполнялись очень мед- 
ленно. 

Очевидно, в силу указанных выше недостатков, сетевые СУБД прак- 
тически прекратили свое существование. 

При реализации иерархических и сетевых баз данных был принят 
принцип, который, как показала практика, имеет серьезные недостатки. 
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Для связывания записей, принадлежащих одному групповому отноше- 
нию, в этих моделях использовались указатели, представляющие собой 
физические адреса данных на диске. Недостатки такого подхода были 
проанализированы в работах Е.Ф.Кодда, которого по праву считают авто- 
ром и идеологом реляционной модели данных. 


3. Реляционная модель данных 


В 1970 гЕ.Ф.Кодд опубликовал 2 статьи, в которых ввел реляцион- 
ную модель данных и реляционные языки обработки данных - реляцион- 
ную алгебру и реляционное исчисление. В своей работе Кодд продемон- 
стрировал недостатки существующих подходов к связыванию данных с 
помощью хранения физических адресов данных (указателей). Он показал, 
что такие базы данных существенно ограничивают число типов манипу- 
ЛЯЦИЙ данными. Более того, они очень чувствительны к изменениям в 
физическом окружении. Когда в компьютерной системе устанавливался 
новый накопитель или изменялись адреса хранения данных, требовалось 
дополнительное преобразование файлов. Если к формату записи в файле 
добавлялись новые поля, то физические адреса всех записей файла изме- 
нялись. То есть такие базы данных не позволяли манипулировать данны- 
ми так, как это позволяла бы логическая структура. Все эти проблемы 
преодолела реляционная модель. 

В реляционной модели достигается гораздо более высокий уровень 
абстракции данных, чем в иерархической или сетевой модели. В статье 
Е.Ф. Кодда утверждается, что "реляционная модель предоставляет средст- 
ва описания данных на основе только их естественной структуры, т.е. без 
потребности введения какой-либо дополнительной структуры для целей 
машинного представления". Другими словами, представление данных не 
зависит от способа их физической организации. 

Основным логическим объектом для хранения данных в реляцион- 
ной модели является таблица. Для организации связей между данными 
различных таблиц используются общие столбцы. Например, для примера 
с подразделениями и сотрудниками понадобятся две таблицы (одну мож- 
но назвать Подразделения, другую - Сотрудники), связанные общим 
столбцом Таким столбцом может быть, например, Лич- 
ный код сотрудника (или табельный номер сотрудника). Более подроб- 
ное неформальное введение в реляционную модель содержится в сле- 
дующем разделе данной лекции. 

Эта простая идея связывания таблиц оказалась столь жизнеспособ- 
ной, что уже на протяжении свыше 30 лет реляционная модель является 
основной в базах данных. Огромное количество данных уже реально хра- 
нится на магнитных носителях в виде таблиц, хорошо проработаны тео- 
ретические основы такого способа хранения данных. В силу указанных 
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обстоятельств новые модели данных вводятся очень осторожно, чтобы не 
разрушить уже функционирующие информационные системы. Тем не 
менее, такие модели данных постепенно вводятся и поддерживаются 
производителями СУБД. 


4. Постреляционная модель данных 


Постреляционная модель в основе содержит реляционную модель, 
дополненную возможностью создания вложенных таблиц. Постреляци- 
онная модель уже поддерживается некоторыми СУБД, например, Отасе, 
Роѕіртеѕ и рядом других, которые содержат такие типы данных как масси- 
вы и таблицы. Однако реальное использование этих новых типов данных 
встречается довольно редко, поскольку СУБД пока не гарантируют такую 
же эффективность работы с вложенными таблицами, как с таблицами, 
содержащими только атомарные (неделимые) значения. 

Если продолжить пример с подразделениями и сотрудниками, то к 
таблице Сотрудники можно было бы добавить столбец Дети, представ- 
ляющий собой вложенную таблицу с именами и датами рождения детей 
сотрудника. Можно было бы добавить и столбец Образование, содержа- 
щий названия учебных заведений, которые закончил данный сотрудник, а 
также даты их окончания и номера дипломов. 


5. Объектно-ориентированная модель данных 


Объектно-ориентированная модель является очень перспективной в 
связи с распространением объектно-ориентированного подхода к разра- 
ботке программных продуктов. На сегодняшний день ее распространение 
сдерживают два обстоятельства: 
® Отсутствие строгой математической модели объектно-ориентирован- 
ной базы данных. Для реляционной модели такое строгое описание 
имеется; 

® Наличие огромного количества данных в имеющихся реляционных 
базах данных и существенные затраты на их конвертацию в объект- 
но-ориентированную БД. 

В силу этих обстоятельств внедрение объектно-ориентированного 
подхода в базы данных происходит эволюционно, без разрушения реля- 
ционной основы. На сегодняшний день многие СУБД позиционируются 
как объектно-реляционные. В их основе по-прежнему лежит реляционная 
модель, но она дополнена возможностью создания пользовательских ти- 
пов столбцов с поддержкой принципов инкапсуляции и наследования. 
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1.3.2. Неформальное введение в реляционную 
модель 


Формальное определение реляционной модели основано на теории 
множеств (математической моделью таблицы является отношение — геіа- 
йоп, отсюда и произошел термин реляционная база данных). Е.Ф. Кодд 
определил систему операций над отношениями (реляционную алгебру) и 
сформулировал основные правила поддержки целостности реляционной 
базы данных. Им же был предложен и язык для манипулирования реля- 
ционной базой данных, который тогда получил название ЗЕООЕГ, а впо- 
следствии превратился в язык ЗОГ.. 

Изучение языка ЗОГ, невозможно без знания основ реляционной мо- 
дели, которую он полностью поддерживает, поэтому в следующих лекци- 
ях будет приведено ее формальное описание, основанное на работах 
Е.Ф.Кодда и К.Дж.Дейта. В качестве введения в реляционную модель 
далее приведем неформальные, но достаточно строгие определения. 


1. Таблицы и связи 


Доктор Кодд выделил 12 принципов (правил) реляционных баз дан- 
ных. Начнем с первого правила, которое позволит понять суть реляцион- 
ной модели: 

® вся информация логически представлена в виде таблиц. 

Таблица состоит из строк и столбцов (в реляционной теории строке 
соответствует кортеж, а столбцу — атрибут, однако в стандарте ЗОГ 
используются общепринятые термины «строка» и «столбец»). 

Поскольку вся информация, хранимая в базе данных, не может быть 
размещена в одной таблице, возникает вопрос, как организовать связи 
между таблицами. Согласно первому правилу Кодда, вся информация, в 
том числе и информация о связях между данными, должна содержаться в 
самих таблицах. В реляционной модели для этого используются общие 
столбцы таблиц. 

Например, пусть в базе данных коммерческой фирмы необходимо 
хранить ряд сведений о клиентах фирмы: 
® порядковый номер (личный код) клиента; 
® фамилия, имя, отчество; 
® контактные телефоны. 


При попытке разместить все эти данные в одной таблице возникает 
серьезная проблема со столбцом «контактные телефоны». Обычно клиен- 
ты оставляют несколько номеров – рабочий, домашний, мобильный теле- 
фон и т.д., причем количество номеров может быть различным (допусти- 
ма даже такая ситуация, когда клиент вообще не предоставляет ни одного 
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номера). Наилучшим способом для хранения контактных телефонов бу- 
дет отдельная (детальная или подчиненная) таблица, связанная с основ- 
ной таблицей данных о клиентах при помощи общего столбца «личный 
код клиента». 

Возможный вариант заполнения таблиц показан на рис. 1.10. 


Клиенты Контактные телефоны 


| код |фамилия имя | отчество телефон | пояснение 
111111 | рабочий 
222222 домашний 


333333333 | мобильный 
123456 рабочий 


Рис. 1.10. Информация о клиентах 
с указанием контактных телефонов 


В данном примере клиенту с кодом 1 соответствуют три связанных 
строки в таблице Контактные телефоны (у них всех в столбце код стоит 
значение 1), а клиенту с кодом 2 — только одна связанная строка. Получи- 
лась очень стройная и логичная структура из двух связанных таблиц, с 
помощью которой одинаково легко найти как все номера телефонов 
конкретного клиента, так и определить, какому клиенту принадлежит тот 
или иной телефон. 

Рассмотрим еше один пример организации связи между таблицами в 
реляционной базе данных. например, товары и поставщики. Пусть необ- 
ходимо хранить сведения о товарах и их поставщиках. В данном случае 
связь между товарами и поставщиками несколько сложнее, чем между 
клиентами и их телефонами. Каждый товар может поставлять, как прави- 
ло, несколько фирм-поставщиков, но и каждая такая фирма обычно по- 
ставляет несколько товаров. В этом случае наилучшим решением будет 
создание еще одной таблицы, которую называют таблицей-связкой, для 
хранения информации о связях между товарами и их поставщиками. 

Пример заполнения такой базы данных показан на рис. 1.11, здесь 
таблица-связка названа, как обычно принято, Товары-поставщики и со- 
держит всего два столбца – код товара и код поставщика. В таблицах- 
связках могут быть и дополнительные, уточняющие, столбцы, например, 
цена данного товара у данного поставщика и т.д. 
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Товары Товары-поставщики Поставщики 
товара | поставщи 
1 


Ӯ наименование 


1 | скатерть 
2 | салфетка 


2 Льнокомбинат 


3 | наволочка | 


Рис. 1.11. Информация о товарах и их поставщиках 


2. Первичные, альтернативные и внешние ключи 


Обобщим материал приведенных примеров. Рассмотрим, например, 
связь между таблицами Клиенты и Контактные телефоны. В таблице 
Клиенты столбец «код» является уникальной характеристикой каждого 
клиента, такой столбец называется первичным ключом (Рптагу Кеу -РК). 
Прилагательное «первичный» добавляется в связи с тем, что уникальных 
столбцов или уникальных сочетаний нескольких столбцов в реальных 
таблицах может быть несколько. Например, в таблицу Клиенты можно 
было бы добавить столбец серия и номер паспорта (или два столбца — 
серия и номер отдельно), и это был бы альтернативный ключ таблицы 
(если уникальный ключ состоит из нескольких столбцов, то он называет- 
ся составным). Заметим, что сочетание фамилии, имени и отчества нель- 
зя считать альтернативным ключом ввиду наличия полных однофамиль- 
цев. Сочетания двух столбцов «код» и «фамилия» или «код» и «имя», 
конечно, обладают свойством уникальности, но это явно избыточные со- 
четания (фамилию или имя можно отбросить без потери уникальности). 
Таким образом, ключ таблицы должен удовлетворять двум признакам — 
уникальности и безизбыточности. 

Второе правило Кодда гласит — логический доступ к данным осу- 
ществляется по имени таблицы, имени столбца и значению первичного 
ключа. Эти три составляющих позволяют однозначно получить любой 
элемент реляционной базы данных. Например, по таблице клиенты, 
столбцу фамилия и значению кода 2 легко получить фамилию Петров. 

Связь главной и подчиненной таблиц обычно осуществляется с по- 
мощью первичного ключа главной таблицы, который помещается (экс- 
портируется) в подчиненную таблицу и становится там внешним ключом 
(Еоте1еп Кеу - ЕК). Внешний ключ не обладает свойством уникальности 
(каждому клиенту может соответствовать несколько номеров телефонов, 
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каждому поставщику — несколько товаров), обычно он является частью 
составного первичного ключа или неключевым столбцом. 

В примере с клиентами и телефонами подчиненная таблица имеет 
составной первичный ключ «код» и «номер телефона» - вместе они обра- 
зуют уникальное и безизбыточное сочетание. Связь между таблицами 
Клиенты и Контактные телефоны называют связью «один ко многим» 
(тут прямая аналогия с иерархической и сетевой базами данных). 

В примере с товарами и поставщиками, как правило, наименования 
всех товаров и названия всех фирм-поставщиков сами по себе уникальны. 
Однако введение дополнительных ключевых столбцов, иначе называемых 
суррогатными ключами, является повсеместной практикой. Допустим, 
если какая-либо фирма-поставщик изменила название, чтобы отразить это 
изменение в базе данных, достаточно исправить всего одно значение в 
таблице Поставщики. Изменять суррогатный ключ при этом не нужно, 
поэтому информация в таблице-связке останется прежней. 


3. МОШЕ -значения 


МОЦ -значения — это неопределенные или пустые значения дан- 
ных, которые в реляционной теории трактуются как отсутствие информа- 
ции (правило Кодда №3). Их нельзя рассматривать как нулевые значения 
числовых полей или пустые строки в текстовых полях. Допустимость 
пустых значений в том или ином столбце необходимо указывать при оп- 
ределении таблиц. 

В отношении ключевых столбцов справедливы следующие правила: 

® в первичном и альтернативном ключах МОЛІ -значения не допус- 
каются; 

® во внешнем ключе наличие МОГГ-значений допустимо, однако 
при определении таблицы их можно запретить. 

Существуют определенные правила обработки МОЛІ -значений. Два 
МОГ -значения никогда не равны друг другу. 


4. Метаданные. Схема базы данных 


Описание структуры базы данных называется метаданными (данные 
о данных). Метаданные должны храниться в базе данных, как и все про- 
чие значения, а не в прикладной программе (правило Кодда №4). 

Для наглядного представления структуры базы данных, удобного 
для пользователей, используется ее графическое изображение, которое 
называется схемой. Изобразим логическую схему базы данных Сведения 
о клиентах, воспользовавшись международным стандартом ІРЕҒІХ 
(рис.1.12). 
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клиенты 


контактные телефоны 
телефон 
код ГЕК) 


пояснение 


Рис. 1.12. Логическая схема базы данных 
Сведения о клиентах 


Как видно из схемы, главная и подчиненная таблицы неразрывно 
связаны друг с другом, и эта связь имеет логический характер, не завися- 
щий от физического способа реализации таблиц. 


5. Правила ссылочной целостности 


Внешний ключ подчиненной таблицы можно рассматривать как 
ссылку на строку главной таблицы с таким же значением первичного 
ключа. Отсюда вытекает основное правило ссылочной целостности 
— все значения внешнего ключа должны быть согласованы с соот- 
ветствующими значениями первичного ключа. Применительно к на- 
шему примеру это означает, что в таблице контактные телефоны не 
должно быть кодов клиентов, которых нет в основной таблице 
клиенты. 

Ссылочная целостность должна жестко контролироваться при вы- 
полнении любых операций с данными таблиц (правило Кодда №12). 

Правило Кодда №7 устанавливает 4 таких операции — извлечение, 
вставка новых строк, удаление строк и изменение (обновление) сущест- 
вующих строк (операции ѕеІесі, іпѕегі, две, ирда{е). Операция извлече- 
ния не может нарушить целостности, т.к. не изменяет данные. Рассмот- 
рим основные стратегии поддержки ссылочной целостности для осталь- 
ных операций. 

Операция вставки критична только для подчиненной таблицы (мож- 
но добавить нового клиента, у которого нет телефона, но нельзя добавить 
телефон несуществующего клиента), поэтому вставка новых строк в под- 
чиненную таблицу должна проверяться на согласованность значений 
внешнего ключа. 

Удаление строк подчиненной таблицы, наоборот, абсолютно безо- 
пасно (можно удалить любой телефон, не нарушив ссылочной целостно- 
сти). Однако удаление строк главной таблицы при наличии связанных 
строк в подчиненной таблице непременно приведет к нарушению ссы- 
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лочной целостности, чего допустить нельзя ни в коем случае. Здесь име- 
ется две основных стратегии удаления: 

® запрет удаления таких строк (ограничение удаления - геѕігісі), 

® каскадное удаление строки главной таблицы вместе со всеми свя- 

занными строками подчиненной таблицы (удаление каскадом - 
саѕсаде). 

В нашем конкретном примере с телефонами разумным решением 
будет каскадное удаление (при удалении клиента автоматически должны 
удаляться и все строки с его телефонами). В реальной практике чаще 
применятся запрет удаления строк при наличии на них хотя бы одной 
ссылки из других таблиц. Отметим, что ни одна СУБД не позволит уда- 
лить всю таблицу целиком, если имеется хотя бы одна другая таблица, 
которая на нее ссылается. 

Изменение (обновление) значений внешнего, а особенно первичного 
ключа заполненной базы данных обычно не происходит, однако стратегия 
каскадного обновления некоторыми СУБД поддерживается. 

В следующей главе пособия реляционная модель данных будет оп- 
ределена более формально. Наличие формального математического опи- 
сания считается одним из достоинств реляционной модели. 
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2. Реляционная модель 


Цель изучения данной главы — освоить реляционную модель данных 
как математическую основу языка ЗОГ. 

После изучения главы вы будете: 
® знать реляционную терминологию, понимать определения основных 
реляционных терминов 
® знать операции реляционной алгебры, отличия реляционной алгебры 
от реляционного исчисления, понимать логику разработки запросов в 
терминах реляционной алг ебры и реляционного исчисления 
• знать правила поддержки целостности данных при выполнении ос- 
новных операций манипулирования данными. 

В реляционной модели выделяют три части: 
• Структурная часть 
® Манипуляционная часть 
® Целостная часть 
Рассмотрим каждую из них подробнее. 


2.1. Реляционная модель. Структурная 
и целостная части 


2.1.1. Структурная часть 


Реляционная модель данных является математической основой язы- 
ка ЗОГ, в которой приведено строгое формальное описание всех реляци- 
онных объектов, и се изучение интересно именно с этой точки зрения. 

Такие понятия, как таблица, строка, столбец и т.д., являются точны- 
ми, но недостаточно формальными терминами для строгого математиче- 
ского описания реляционных объектов. При разработке реляционной мо- 
дели за основу была принята теория множеств, а в качестве математиче- 
ской модели таблицы используется отношение (ғеіаііоп), которое опре- 
деляется в терминах теории множеств. Собственно, и термин «реляцион- 
ная» произошел от английского термина те!аноп (иногда в литературе 
используется термин «реляция»). Соответствие между реляционной и 
общепринятой терминологией приведено ниже. 


Соответствие между реляционными и общепринятыми терминами 


Общепринятый термин Реляционный термин 

Таблица Отношение 

Строка Кортеж 

Столбец Атрибут 

Множество допустимых значений столбца Домен, на котором определен атрибут 
Количество столбцов Степень или арность 

Количество строк Кардинальное число 
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Для каждого реляционного термина приведем его формальное опре- 
деление. 


2.1.2. Атрибуты и домены. Схема отношения 


Атрибут определяется как именованный атомарный (неделимый) 
элемент данных. Множество допустимых значений атрибута называется 
доменом, на котором определен данный атрибут. Каждый атрибут опре- 
делен на своем домене, при этом допустимы одинаковые домены для раз- 
личных атрибутов. Сравнивать между собой можно только значения ат- 
рибутов, определенных на одинаковых доменах. 

Определение домена очень близко к определению типа данных в 
языках программирования. В самом общем виде домен определяется за- 
данием некоторого базового типа данных и произвольного логического 
выражения, применяемого к каждому элементу данных. Если вычисление 
этого логического выражения дает результат "истина", то элемент данных 
является элементом домена. 

В большинстве реляционных СУБД объект «домен» не использует- 
ся, но для каждого атрибута задается базовый тип и ряд ограничений (соп- 
ѕіғаіпіѕ), которые проверяются для каждого значения атрибута. В послед- 
нем стандарте ЗОГ, специфицирована команда сгесе ѓуре... , которая по- 
зволяет конструировать произвольные типы данных, что еще точнее со- 
ответствует понятию домена, введенного Коддом для реляционных баз 
данных. 

Схема отношения - это именованное множество упорядоченных пар 

(имя атрибута : имя домена). 

Степень или "арность" схемы отношения - мощность этого множест- 
ва (количество элементов, входящих в множество). Например, если в 
схему отношения входит всего два атрибута, то отношение называется 
бинарным, если три – тернарным. 

Схема БД - это набор именованных схем отношений. 


2.1.3. Кортежи. Отношение 


Кортеж, соответствующий данной схеме отношения, - это множест- 
во упорядоченных пар 

(имя атрибута : значение атрибута), 
которое содержит по одному вхождению каждого имени атрибута, при- 
надлежащего схеме отношения. 

Значение атрибута является допустимым значением из домена дан- 
ного атрибута. Арность кортежа, т.е. число элементов в нем, совпадает с 
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арностью соответствующей схемы отношения. Таким образом, можно 
считать кортеж математической моделью одной (любой) строки таблицы. 
Отношение - это множество кортежей, соответствующих одной 
схеме отношения. В определении Дейта [1] схема отношения называется 
заголовком отношения, а множество кортежей - телом отношения. Заго- 
ловок отношения соответствует заголовку («шапке») таблицы, тело от- 
ношения соответствует всей совокупности данных, содержащихся в таб- 
лице. 
Из определения отношения следуют его основные свойства: 
» в отношении не может быть двух одинаковых кортежей (согласно 
определению множества, все его элементы уникальны), 
® кортежи не упорядочены, атрибуты также не упорядочены (это свой- 
ство также является неотъемлемым свойством любого множества). 
Добавим к этому, что имена всех атрибутов в пределах одного от- 
ношения должны быть уникальны. 
Реляционная база данных - это набор отношений, имена которых 
совпадают с именами схем отношений в схеме БД. 


2.1.4. Потенциальные ключи. Первичный ключ 


Согласно свойствам отношений, каждый кортеж в целом уникален, 
однако отдельные атрибуты могут содержать и повторяющиеся значения. 
Тем не менее, в каждом отношении можно выделить хотя бы одну группу 
(подмножество) атрибутов (возможно, один атрибут), содержащих гаран- 
тированно уникальные значения. 

Потенциальным ключом отношения (Сапаіааіе Кеу - СК) называют 
подмножество атрибутов отношения, которое удовлетворяет двум свой- 
ствам: 

1. Уникальность (не существует двух одинаковых значений); 

2. Безизбыточность (никакое подмножество потенциального ключа 

не является потенциальным ключом). 

Различают простые и составные потенциальные ключи (например, 
серия и номер паспорта – составной потенциальный ключ, а ИНН - про- 
стой). 

В каждом отношении можно выделить один или несколько потенци- 
альных ключей. Если таких ключей несколько, один из них выбирается в 
качестве первичного ключа (Рипаку Кеу - РК). 

Первичные ключи используются в качестве общих столбцов для свя- 
зывания таблиц. Поэтому в качестве первичного ключа обычно выбира- 
ют самый короткий, чаще всего, числовой атрибут, для которого гаранти- 
руется не только уникальность, но и неизменность значений. На практике 
часто невозможно выделить такой атрибут, в этом случае используют 
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дополнительный атрибут, называемый суррогатным ключом, который 
автоматически заполняется уникальными значениями и никогда не изме- 
няется. 

Все потенциальные ключи отношения, которые не являются пер- 
вичным ключом, называются альтернативными ключами. 

Пи в одном из потенциальных ключей МО М.--значения недопустимы. 


2.1.5. Внешние ключи 


Первичные ключи отношений используются в качестве общих атри- 
бутов при связывании отношений. Для этой цели вводятся понятия роди- 
тельского (главного) отношения и дочернего (подчиненного) отношения. 
Первичный ключ родительского отношения, экспортированный в дочер- 
нее отношение в качестве связующего атрибута, называется внешним 
ключом дочернего отношения. Посредством внешнего ключа кортежи 
дочернего отношения ссылаются на соответствующие им кортежи роди- 
тельского отношения. 

Определим данное понятие более формально. Назовем внешним 
ключом (югаеп кеу - ЕК) такое подмножество атрибутов дочернего от- 
ношения, что для любого его непустого значения обязательно найдется 
равное значение первичного ключа главного отношения. 

Обратное утверждение несправедливо, т.е. в родительском отноше- 
нии могут найтись такие кортежи, на которые не ссылаются никакие кор- 
тежи дочернего отношения. Например, в отношении Сотрудники могут 
быть кортежи, для которых нет ни одного связанного кортежа в отноше- 
нии Дети Сотрудников. 

Значения внешних ключей не обязаны быть (и обычно не бывают) 
уникальными в своем отношении (продолжая пример с сотрудниками и 
детьми — у сотрудников может быть несколько детей, все они содержит 
одинаковые значения внешнего ключа). 

Во внешнем ключе МОГ.Г-значения допустимы, в отличие от пер- 
вичного ключа, однако на практике такая необходимость встречается 
крайне редко. 


2.1.6. Целостная часть реляционной модели 


Целостность данных - это механизм поддержания базы данных в не- 
противоречивом состоянии, соответствующем динамично изменяющейся 
предметной области. 

Угроза нарушения целостности данных возникает при выполнении 
операций манипулирования данными. Поэтому все СУБД должны кон- 
тролировать операции вставки (Іпѕет), удаления (рае) и обновления 
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(Орда) и отказывать в выполнении операции, если в ней проводится 
попытка нарушить целостность базы данных. Эта проблема решается пу- 
тем введения специальной системы мер, не позволяющих, например, вво- 
дить в БД данные заведомо неверного типа, дублирующиеся значения 
первичных ключей и т.п. Набор определенных правил, устанавливающих 
допустимость значений данных и их связей, называют правилами или ог- 
раничениями целостности (сопѕіғаїпіҳ). 

Ограничения целостности задаются и хранятся в словаре данных БД 
как один из элементов определения таблицы, к которой они относятся. 
Тем самым любое приложение, обрашающееся к этой таблице, необходи- 
мым образом должно придерживаться заданных правил. Изменения пра- 
вил целостности может быть произведено на уровне базы данных в це- 
лом, а не для отдельного приложения. Это еще один из примеров вопло- 
щения принципа независимости данных и прикладного ПО. 

Большинство БД подчиняется очень многим правилам поддержки 
целостности. Есть специфические (корпоративные) правила, которые ха- 
рактерны только для конкретной предметной области и применяется 
только к одной БД). Есть два общих особых правила, они применяются к 
любой БД и относятся к потенциальным (и первичным) ключам и ко 
внешним ключам. 

В реляционной модели данных определены два базовых универсаль- 
ных требования обеспечения целостности: 

е целостность сущностей, 

® целостность ссылок. 


Целостность сущностей 


Объект реального мира (сущность) представляется в реляционной 
базе данных как кортеж некоторого отношения. Требование целостности 
сущностей заключается в следующем: 

каждый объект реального мира должен быть четко идентифициро- 
ван, т.е. любое отношение должно обладать первичным ключом. 

Вполне очевидно, если данное требование не соблюдается, то в базе 
данных может храниться противоречивая информация об одном и том же 
объекте. Поддержание целостности сущностей обеспечивается средства- 
ми СУБД. Это осуществляется с помощью двух ограничений: 

• при добавлении кортежей проверяется уникальность их первичных 
ключей и отсутствие в них МОЛІ -значений, 

® не позволяется изменение значений атрибутов, входящих в первич- 
НЫЙ КЛЮЧ. 
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При попытке внести любое изменение в базу данных, нарушающее 
целостность сущностей, операция прерывается, а база данных остается в 
исходном, согласованном, состоянии. 


Целостность ссылок (ссылочная целостность) 


Сложные объекты реального мира представляются в реляционной 
базе данных в виде кортежей нескольких отношений, связанных между 
собой с помощью внешних ключей. 

Требование целостности по ссылкам состоит в следующем: 

все значения внешних ключей ДОЛЖНЫ быть согласованы. 

Выполнение этого требования любая СУБД контролирует автомати- 
чески, при этом для каждой из операций манипулирования данными вы- 
полняются свои специфические действия. Безусловно, поддержка целост- 
ности отнимает много ресурсов, при этом существенно замедляется вы- 
полнение операций манипулирования данными, однако гарантированное 
обеспечение целостности ссылок стоит всех этих затрат. 

Правила поддержки ссылочной целостности зависят от выполняемой 
операции манипулирования данными. 

При выполнении операции вставки ссылочная целостность контро- 
лируется только в случае наличия внешних ключей, ссылающихся на дру- 
гие отношения. В этом случае проверяется существование соответствую- 
щих значений первичных ключей, в случае их отсутствия операция встав- 
ки отменяется. 

Наиболее остро стоит проблема обеспечения ссылочной целостности 
при выполнении операции удаления кортежей родительского отношения, 
на которые есть ссылки в дочерних отношениях (возможно, сразу в не- 
скольких). В этом случае простое удаление кортежа приведет к наличию 
несогласованных значений внешних ключей во всех дочерних отношени- 
ях. Обеспечить ссылочную целостность при удалении можно нескольки- 
ми способами: 

1. Запретить удаление кортежей в родительском отношении при нали- 
чии хотя бы одного ссылающегося кортежа (геѕігпісі - ограничить уда- 
ления); 

2. При удалснии кортсжа родитсльского отношения каскадом удалять 
все ссылающиеся на него кортежи дочернего отношения (саѕсайе — 
каскадное удаление); 

3. При удалении кортежа родительского отношения установить во всех 
ссылающихся кортежах МОГТ-значения во внешних ключах (561 пи). 
Этот способ можно применять только в случае, если МІЛІ -значения 
в соответствующем внешнем ключе разрешены; 

4. При удалении кортежа родительского отношения установить во всех 
ссылающихся кортежах значения по умолчанию во внешних ключах 
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(ѕеі аси. Значения по умолчанию задаются при создании базы 

данных. 

Из предложенных способов наиболее безопасным является первый — 
запрет удаления, он применяется чаще всего. Способ каскадного удале- 
ния следует применять очень осторожно. 

При выполнении операций обновления во внешних ключах ссылоч- 
ная целостность обеспечивается так же, как и при добавлении нового кор- 
тежа. Обновление первичных ключей при наличии ссылающихся внеш- 
них ключей категорически не рекомендуется. Вообще выполнять обнов- 
ление первичных ключей нет никакой необходимости, даже если СУБД 
разрешает такую возможность. 


2.2. Манипуляционная часть реляционной 
модели 


В реляционной модели определяются два базовых механизма мани- 
пулирования данными: 

основанная на теории множеств реляционная алгебра; 

основанное на математической логике реляционное исчисление. 

Так же, как и выражения реляционной алгебры, формулы реляцион- 
ного исчисления определяются над отношениями реляционных баз дан- 
ных, и результатом вычисления всегда является новое отношение. Новое 
отношение, полученное из одного или нескольких имеющихся отноше- 
ний, называется производным отношением. Исходные отношения, вхо- 
дящие в состав базы данных, называются базовыми. 

Реляционная алгебра и реляционное исчисление различаются степе- 
нью их процедурности: 

•запрос, представленный на языке реляционной алгебры, может быть 
вычислен на основе вычисления элементарных алгебраических операций 
с учетом их старшинства и возможных скобок, 

•формула реляционного исчисления только устанавливает условия, ко- 
торым должны удовлетворять кортежи результирующего отношения. По- 
этому языки реляционного исчисления являются более непроцедурными 
или декларативными. 

Язык БОГ, основывается на реляционной алгебре, однако содержит 
некоторые элементы реляционного исчисления. 


2.2.1. Реляционная алгебра 


Поскольку отношение в реляционной алгебре определяется как 
множество кортежей, то на отношения распространяются основные опе- 
рации над множествами – объединение, пересечение, разность и декарто- 
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во произведение. Операции объединения, пересечения и разности опре- 
делены для отношений, схемы которых могут отличаться только именами 
атрибутов (т.е. отношения имеют одинаковую степень и атрибуты опре- 
делены на одних и тех же доменах). 
1. Объединение КЗ= В1СК2 

В результат КЗ помещаются все кортежи, которые есть в КІ или в 
В2, причем кортежи, которые одновременно присутствуют в КІ и Е2, 
помещаются в результат один раз. 


В! В2 
1|А Зе УС 
2 ІВ 4 [р 
з [С 5 [Е 
Результат ВЗ 

1 А 

2 В 

3 С 

4 р 

5 Е 


2. Пересечение КЗ=К1/ К2 

В ВЗ помещаются кортежи, которые есть в КІ ив 2. 

Для КІ и Е2 из предыдушего примера результатом будет единственный 
кортеж (3,С). 


3. Разность КЗ=В1-В2 
В КЗ попадут кортежи, которые есть в КІ, но нет в В2 


ВІ В2 
И: ЗК 
2 [В 4 [р 
С ВИ: 
Результат ВЗ 

1 [А 

2: [В 


Заметим, что операция пересечения может быть вычислена через 
операции разности КЗ=В1^ К2=К1-(В1-В2) 
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4. Декартово произведение КЗ=Е1хК2 

Результат получается путем склейки каждого кортежа отношения КІ с 
каждым кортежем В2. 

с=а*р 

а- количество кортежей в КІ 

Ь- количество кортежей в В2 

с- количество кортежей в КЗ 

При этом степень КЗ равна сумме степеней КІ и К2 


КІ В2 

11| А Зь АС 
2 |В 4 1р 
ЗС 5 [Е 


Результат ВЗ 
1 


сә [м | ә |м | әм 
ооо“ 
л лол |ә чә 
озере оное отоо! 


Кроме перечисленных операций над множествами, Кодд ввел ряд 
дополнительных операций над отношениями. Операции проекции и вы- 


борки определены над одним отношением КІ (унарные операции). 


5. Проекция – отбор атрибутов отношения 
В2=л: (КІ) 

І – подмножество атрибутов отношения КІ 
Степень результата В2 равна | І | - количество элементов в подмножестве 
Ги может принимать целые значения от 1 до степени КІ. 


Пример: проекция КІ из предыдущих примеров по 2-му атрибуту 
Результат К2 содержит всего один атрибут. 
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6. Операция выборки (селекции) — отбор кортежей 

К2=со (КІ) 

Ө - любое логическое выражение (условие отбора кортежей), в состав ко- 
торого входят имена атрибутов, операции и константы. 

В В2 включают все кортежи из КІ, для которых Ө - истинно. При этом 
отношение К2 может не содержать ни одного кортежа или совпадать с 
отношением КІ. Например, при условии отбора 

первый атрибут > 0 

в Е? попадут все кортежи КІ, а при условии 

перый атрибут > 2 

только один кортеж (3,С) 

На практике операции выборки и проекции часто сочетаются в одном 
запросе. 


7. Операция соединения КЗ= КІӨК2 
Данная операция определена над двумя отношениями, у которых 
есть общее подмножество атрибутов (на практике это чаще всего один 
общий атрибут, по которому и выполняется операция соединения). В от- 
личие от операции декартова произведения при соединении склеиваются 
только те кортежи КІ и В2, которые имеют одно и то же значение общего 
атрибута (а не каждый кортеж с каждым). При этом общий атрибут попа- 
дает в результат один раз. 
Пример. Пусть выполняется операция соединения по первому из атрибу- 
тов (содержащему числовые значения) 
ВІ А2 
ЕЕ Е 
2 |В 2 1р 
С Е 
Е 


Результат ВЗ 


2 В С 
2 В р 
3 С Е 


Операция соединения эквивалентна операции выборки из декартова 
произведения отношений КІ и Е2. 
В3= КІӨВ2=сь (КІХВ2) 

Однако, учитывая большую важность этой операции для реляцион- 
ной базы данных, где связь между отношениями устанавливается при 
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помощи общих атрибутов, она включена в состав базовых операций ре- 
ляционной алгебры. 

Следует отметить, что в результат операции соединения не входят 
кортежи отношений КІ и В2, для которых не находится одинаковых значе- 
ний в общем атрибуте. Так, в предыдущем примере в результат не вошел 
кортеж (1,А) из отношения КІ и (4,Е) из отношения В2. Ввиду этой осо- 
бенности данную операцию называют операцией внутреннего соединения. 

В языке ЗОГ, поддерживается три операции внешнего соединения — 
левое, правое и полное. 

В левом внешнем соединении результат внутреннего соединения до- 
полняется оставшимися кортежами отношения, стоящего слева (в приме- 
ре это кортеж (1,А) из отношения КТ). Поскольку в результате должно 
быть 3 атрибута, незаполненный атрибут принимает значение МІЛІ, т.е. 
в результат КЗ добавляется кортеж (1, АЛМОТГ). 

В правом внешнем соединении результат внутреннего соединения 
дополняется оставшимися кортежами отношения, стоящего справа (в 
примере кортеж (4,Е) из отношения К2 дополняется значением МОГ, и 
получается кортеж (4,МОГТ.,Е) отношения КЗ). 

Наконец, в полном внешнем соединении в результат добавляются 
все несвязанные кортежи, дополненные неопределенными значениями (в 
примере это два упомянутых выше кортежа). 


8. Операция деления КЗ= КІ + К2 

Для выполнения операции деления отношения КІ и К? должны иметь 
общее подмножество атрибутов (обычно один атрибут), причем в отно- 
шении В2 это подмножество является множеством его атрибутов (обычно 
В? является унарным отношением). Смысл операции поясним на приме- 


ре. 

ВІ В2 

1 А А 
В В 

2 С 

3 А 

3 В 

4 А 

В результате получаем отношение 

ВЗ 

1 

3 


Операция деления явно не поддерживается в языке ЗОГ, хотя имеет- 
ся несколько способов выразить ее через другие операции. 
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2.2.2. Реляционное исчисление 


Разницу между реляционной алгеброй и реляционным исчислением 
поясним на примере. 
Пример: Пусть даны два отношения: 
СОТРУДНИКИ (СОТР_НОМЕР, СОТР ИМЯ, СОТР ЗАРПЛ, 
ОТД НОМЕР) 
ОТДЕЛЫ(ОТД НОМЕР, ОТД КОЛ, ОТД НАЧ) 

Мы хотим узнать имена и номера сотрудников, являющихся началь- 
никами отделов с количеством работников более 10. 

Выполнение этого запроса средствами реляционной алгебры распа- 
дается на четко определенную последовательность шагов: 
1. Выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по ус- 
ловию СОТР НОМ = ОТДЕЛ НАЧ. 
СІ = СОТРУДНИКИ [СОТР НОМ = ОТД НАЧ] ОТДЕЛЫ 


2. Из полученного отношения произвести выборку по условию 
ОТД КОЛ>10 
С2= СІ [ОТД КОЛ > 10]. 


3. Спроецировать результаты предыдущей операции на атрибуты 
СОТР ИМЯ, СОТР НОМЕР 
СЗ = С2 [СОТР_ ИМЯ, СОТР_НОМЕР] 

Заметим, что порядок выполнения шагов может повлиять на эффек- 
тивность выполнения запроса. Так, время выполнения приведенного вы- 
ше запроса можно сократить, если поменять местами этапы (1) и (2). В 
этом случае сначала из отношения СОТРУДНИКИ будет сделана выборка 
всех кортежей со значением атрибута ОТДЕЛ КОЛ > 10, а затем выпол- 
нено соединение результирующего отношения с отношением ОТДЕЛЫ. 
Машинное время экономится за счет того, что в операции соединения 
участвуют меньшие отношения. 

На языке реляционного исчисления данный запрос может быть запи- 
сан как: 

Выдать СОТР ИМЯ и СОТР НОМ для СОТРУДНИКИ таких, что 
существует ОТДЕЛ с таким же, что и СОТР НОМ значением ОТД НАЧ 
и значением ОТД КОЛ большим 50. 

Здесь мы указываем лишь характеристики результирующего отно- 
шения, но не говорим о способе его формирования. СУБД сама должна 
решить, какие операции и в каком порядке надо выполнить над отноше- 
ниями СОТРУДНИКИ и ОТДЕЛЫ. Задача оптимизации выполнения за- 
проса в этом случае также ложится на СУБД. 

Рассмотренная система операций реляционной алгебры и ряд пред- 
ложений реляционного исчисления были приняты в качестве функцио- 
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нальной спецификации при разработке одной из самых мощных операций 
языка 801. – операции выборки ЗЕГЕСТ, которая используется в подав- 
ляющем большинстве современных информационных систем для извле- 
чения и обработки данных, обеспечивая потребности пользователей при 
решении различных типовых задач автоматизации. 

В следующей главе будут рассмотрены теоретические и практиче- 
ские аспекты проектирования реляционных баз данных. 


3. Проектирование базы данных 


Цель изучения данной главы — освоить общепринятые способы про- 
ектирования базы данных. 


После изучения главы вы будете: 

• знать основные нотации представления диаграмм «сущность - связь»; 

• уметь построить диаграмму «сущность - связь» по известной системе 
бизнес-правил предметной области, используя Сазе-систему (или без 
ее использования); 

® знать требования всех нормальных форм, уметь выявлять нарушения 
нормальных форм и выполнять декомпозицию отношений; 

® знать преимущества и недостатки нормализации, причины для внесе- 
ния сознательной денормализации в структуру базы данных; 

• иметь представление о хранилищах данных и принципах их органи- 
зации 

® иметь представления об ОІТР и ОГ.АР-системах, принципах их орга- 
низации. 


3.1. Семантический анализ предметной 
области 


Предметная область - часть реального мира, подлежащая изучению с 
целью организации управления и, в конечном счете, автоматизации. 
Предметная область представляется множеством фрагментов, например, 
предприятие - цехами, дирекцией, бухгалтерией и тд. Каждый фрагмент 
предметной области характеризуется множеством объектов и процессов, 
использующих объекты, а также множеством пользователей, характери- 
зуемых различными взглядами на предметную область. 
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3.1.1. Трехуровневая модель АМЅІ/ЅРАКС 


В процессе проектирования базы данных рекомендуется использовать 
трехуровневую схему описания данных (так называемая трехуровневая 
модель АМЅІ/ЅРАВС). Проект трехуровневой модели был выдвинут в 
1975 году подкомитетом ЅРАВС (Ѕ(апаагаѕ РІаппіпр апа Ведитетет$ 


Сошииее) АМ№МІ и имел целью выделить 3 уровня описания данных 
предметной области, различающихся степенью абстракции (рис.3.1). 


внешняя схема 


внешняя схема концептуальная внутренняя 
схема схема 
внешняя схема 


Внешнее представление (внешняя схема) данных является совокупно- 
стью требований к данным со стороны некоторой конкретной функции, 
выполняемой пользователем. Поскольку пользователей много и их пред- 
ставления о данных предметной области существенно различаются, в про- 
цессе анализа предметной области может быть сформировано несколько 
внешних схем (допустим, данные, которые требуются для сотрудников 
бухгалтерии, отдела кадров, планово-финансового отдела ит.д.). 

Концептуальная схема является полной совокупностью всех требо- 
ваний к данным, полученной из пользовательских представлений о ре- 
альном мире. Концептуальная схема описывает все элементы данных и 
связи между ними, с указанием необходимых ограничений поддержки 
целостности данных. Для каждой базы данных имеется только одна кон- 
цептуальная схема. В процессе разработки — это схема проектировщика 
базы данных, в процессе сопровождения системы — это представление 
администратора базы данных (АБД). 

Важно отметить, что внешние схемы и концептуальная схема отно- 
сятся к логическому уровню представления базы данных, т.е. не учитыва- 
ют особенностей СУБД, которая используется для создания и поддержки 
БД - имена типов данных, принятых в СУБД, физические имена файлов, 
способ хранения данных и.т.д. В связи с этим трудно провести четкую 
грань между двумя понятиями, применяемыми в теории проектирования 


Рис. 3.1. Модель АМЉГЅРАКС 
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баз данных – концептуальная схема и логическая схема. Будем считать, 
что концептуальная схема базы данных — это схема логического уровня, 
которая содержит полное описание данных предметной области и связей 
между ними. Все внешние схемы могут быть выведены из концептуаль- 
ной, но процесс проектирования начинается с внешних схем, поскольку 
каждый из пользователей владеет только частью информации о предмет- 
ной области. 

Внутренняя схема – это уровень разработчиков СУБД и, частично, 
АБД и системного администратора. Внутренний уровень описывает фи- 
зическую реализацию базы данных и предназначен для достижения оп- 
тимальной производительности, обеспечения экономного использования 
дискового пространства, организации мероприятий по защите данных. Он 
содержит детальное описание структур данных и физической организа- 
ции файлов с данными, описание вспомогательных структур (индексов), 
используемых для ускорения поиска, сведения о распределении дисково- 
го пространства для хранения данных и индексов, сведения о сжатии дан- 
ных и выбранных методах их шифрования и т.д. В настоящее время про- 
изводители СУБД предоставляют АБД довольно много информации о 
физической организации базы данных, поскольку уровень развития СУБД 
еще не настолько высок, чтобы все настройки, необходимые для опти- 
мального функционирования базы данных, можно было выполнить авто- 
матически. 

Как показывает изучение трехуровневой архитектуры БД, концепту- 
альная схема является самым важным уровнем представления базы дан- 
ных. Она поддерживает все внешние представления, а сама поддержива- 
ется средствами внутренней схемы. Внутренняя схема является всего 
лишь физическим воплощением концептуальной схемы. Именно концеп- 
туальная схема призвана быть полным и точным представлением требо- 
ваний к данным в рамках некоторой предметной области. 

Процесс разработки концептуальной схемы БД требует глубокого 
анализа семантической информации о предметной области. Этот началь- 
ный этап проектирования получил название семантического анализа 
предметной области. В результате анализа должны быть определены все 
элементы данных предметной области в контексте их взаимосвязи с дру- 
гими данными. 


3.1.2. Диаграммы «сущность - связь» 


Удобным средством представления концептуальной схемы БД явля- 
ются диаграммы «сущность - связь» (епйу — ғеіаііопѕћір фазгат, сокра- 
щенно ЕКО). Диаграмма «сущность-связь» была предложена в 1976 г. 
Питером Пин-Шэн Ченом, русский перевод его статьи «Модель "сущ- 
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ность-связь" - шаг к единому представлению данных» опубликован в 
журнале «СУБД» М 3 за 1995 г. 

Важным для нас является тот факт, что из диаграммы «сущность- 
связь» могут быть порождены все существующие модели данных (иерар- 
хическая, сетевая, реляционная, объектная), поэтому она является наибо- 
лее общей. Следует отметить, что современные стандартные способы 
(нотации) для представления диаграмм «сущность - связь» ближе всего к 
реляционной модели, а программное обеспечение для моделирования 
данных обеспечивает автоматическое формирование физической схемы и 
зОГ.-сценария создания БД для распространенных реляционных СУБД. 

Для пояснения основных принципов построения диаграмм «сущ- 
ность - связь» будем пользоваться обозначениями, предложенными авто- 
ром идеи П.Ченом, для обозначения характеристик связей между сущно- 
стями воспользуемся обозначениями, предложенными Мартиным. 

Далее в примерах диаграмм «сущность - связь» будем использовать 
международный стандарт ШЕЕ1Х. 


Элементы диаграммы «сущность - связь» 


Любой фрагмент предметной области может быть представлен как 
множество сущностей, между которыми существует некоторое множест- 
во связей. Дадим определения: 

Сущность - это объект, который может быть идентифицирован не- 
ким способом, отличающим его от других объектов. Сущность имеет 
множество поименованных свойств (атрибутов) и существует во множе- 
стве экземпляров. 

Например, выделим несколько сущностей в предметной области 
Предприятие: Подразделения (атрибуты название, руководитель), Со- 
трудники (атрибуты личный код, ФИО), Дети сотрудников (атрибуты 
имя, дата рождения), Проекты с участием сотрудников (атрибут На- 
звание). 

В нотации П.Чена сущность обозначается прямоугольником, а атри- 


буты — овалом (рис.3.2). 
Са 


подразделения 


сотрудники 


Рис. 3.2. Обозначения для сущностей и атрибутов 
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Связь - это ассоциация, установленная между двумя или нескольки- 
ми сущностями. Особенно часто встречаются бинарные связи, т.е. связи 
между двумя сущностями. 

Роль сущности в связи - функция, которую выполняет сущность в 
данной связи. Обычно роль обозначается глаголом. Например, в связи 
Сотрудники-Дети сущности сотрудники исполняют роль «является ро- 
дителем», а дети — «является ребенком». Указание ролей в модели «сущ- 
ность-связь» не является обязательным и служит для уточнения семанти- 
КИ СВЯЗИ. 

Роль сущности в связи в нотации Чена изображается в виде ромба на 
линии связи. Число экземпляров сущностей, которое может быть ассо- 
циировано через набор связей с экземплярами другой сущности, называ- 
ют мощностью связи. 

Могут существовать следующие мощности бинарных связей. 

Связь один к одному (обозначается 1 : 1 ) 

Это означает, что в такой связи каждому экземпляру одной сущно- 
сти всегда соответствует не более одного экземпляра связанной сущно- 
сти. Так, для сущностей Годразделения и Сотрудники это связь «руково- 
дит», поскольку в каждом подразделении может быть только один на- 
чальник, а сотрудник может руководить только одним подразделением. 
Данный факт представлен на следующем рисунке, где прямоугольники 
обозначают сущности, а ромб - связь. Так как степень связи для каждой 
сущности равна 1, то они соединяются одной линией (Рис.3.3). 


Рис. 3.3. Связь один к одному между сущностями 


Поясним смысл специальных обозначений (вертикальная линия и 
овал) на линии связи. Они характеризуют класс принадлежности входя- 
щих в связь сущностей. Так как в каждом подразделении обязательно 
должен быть руководитель, то каждому экземпляру сущности /7одразде- 
ления непременно должен соответствовать экземпляр сущности Сотруд- 
ники. Однако не каждый сотрудник является руководителем отдела, сле- 
довательно, в данной связи не каждый экземпляр сущности Сотрудники 
имеет связанный экземпляр сущности Подразделения. 

Таким образом, сущность Сотрудники имеет обязательный класс 
принадлежности (этот факт обозначается вертикальной линией), а сущ- 
ность //одразделения имеет необязательный класс принадлежности (обо- 
значается овалом). 

Связь один ко многим (1: М) 
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В данном случае экземпляру сущности может соответствовать любое 
число экземпляров другой сущности. Такова связь Подразделения — Со- 
трудники, при условии, что каждый сотрудник может работать только в 
одном подразделении (на рис. 3.4 показаны две различных связи между 
Сотрудниками и Подразделениями). 


> 


Рис. 3.4. Связи между сущностями Сотрудники и Подразделения 


Данный рисунок дополнительно иллюстрирует тот факт, что между 
двумя сущностями может быть определено несколько связей. Здесь также 
необходимо учитывать класс принадлежности сущностей. Каждый со- 
трудник должен работать в каком-либо отделе, но не каждый отдел (на- 
пример, вновь сформированный) должен включать хотя бы одного со- 
трудника. Поэтому сущность Годразделения имеет обязательный, а сущ- 
ность Сотрудники необязательный классы принадлежности. 

Связь много к одному (М : 1 ) Эта связь аналогична отображению / :М. 

Связь многие ко многим (М :М) 

В этом случае каждая из связанных сущностей может быть пред- 
ставлена любым количеством экземпляров. Пусть сотрудники на рас- 
сматриваемом нами предприятии в процессе своей трудовой деятельно- 
сти участвуют в различных проектах. Поскольку каждый сотрудник мо- 
жет участвовать в нескольких (в том числе и ни в одном) проектах, а каж- 
дый проект может выполняться сразу целой группой сотрудников, то 
связь между сущностями Сотрудники и Проекты имеет степень М: М 
(рис.3.5). 


Рис. 3.5. Связь М:М между Сотрудниками и Проектами 


В заключение приведем небольшой фрагмент диаграммы «сущность 
- связь» для проанализированных сущностей предметной области Лред- 
приятие в нотации П.Чена (с дополнениями Мартина). Он соответствует 
рассмотренным выше бизнес-правилам предприятия. 
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название 


подразделения 


работают в 


руководят 


являются 


‘участвуют в 


проекты 
дата рождения наименование 


Рис. 3.6. Фрагмент диаграммы «сущность - связь» 


Безусловно, реальная подсистема учета персонала предприятия тре- 
бует анализа еще очень многих сущностей и связей. 


3.1.3. САЗЕ-технологии и САЗЕ-системы 


Современные информационные системы имеют очень высокую 
сложность и хранят огромное количество данных. Например, известная 
система дистанционного обучения Моо4е содержит базу данных более 
чем из 200 таблиц (причем в каждой новой версии появляется по не- 
скольку новых таблиц), а ведь эта система считается системой средней 
сложности. Интегрированные системы предприятий могут содержать и до 
1000 таблиц. 


Для автоматизации столь трудоем- 


анализ требований кого процесса, как анализ предметной 
области и разработка концептуальной 

проектирование схемы базы данных, требуется особая 
технология. Такая технология получила 

рсапизация и название САЅЕ (Сотршег Ае4 оўћағе 

Ы ЦЫ аанынан: Епвепеегіпв - создание программного 


обеспечения с помощью компьютера). 
Основные черты САЗЕ - технологии: 
® разработка информационной систе- 


мы представляется в виде последова- 
а аа ыы оонанын тельных четко определенных этапов 
цикла информационной системы 


(рис. 3.7), 
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• поддержка всех этапов жизненного цикла ИС, начиная с анализа 
предметной области до получения и сопровождения готового про- 
граммного продукта, 

® поддержка репозитария, хранящего спецификации проекта ИС на 
всех этапах ее разработки, 

• возможность одновременной работы с репозитарием многих разра- 
ботчиков, 

® автоматизация различных стандартных действий по проектированию 
и реализации ИС. 

Как правило, САЗЕ-системы поддерживают следующие этапы про- 
цесса разработки информационной системы. 
® Моделирование и анализ деятельности пользователей в рамках пред- 

метной области. Здесь осуществляется функциональная декомпози- 
ция, определение иерархий (вложенности) функций, построение диа- 
грамм потоков данных. Перечень информационных объектов, кото- 
рыми манипулируют функции, передается на следующий этап проек- 
тирования. 

® Концептуальное моделирование - создание диаграммы "сущность- 
связь" на основе перечня объектов, полученного на предыдущем этапе. 

® Преобразование диаграммы "сущность-связь" в физическую схему 
базы данных, учитывающую особенности выбранной СУБД. Это пре- 
образование выполняется Сазе-системой автоматически . 

е Автоматическая генерация ЗОГ.-сценария создания базы данных. Ре- 
зультатом выполнения данного этапа является набор ЗОГ- 
операторов, описывающих создание схемы базы данных с учетом 
особенностей выбранной СУБД. 

» Некоторые Сазе-системы выполняют генерацию прототипов про- 
граммных модулей прикладного программного обеспечения, заготов- 
ки экранных форм и отчетов. 

В настоящее время имеется большое количество САЗЕ-систем, под- 
держивающих разные нотации изображения диаграмм «сущность - 
связь». Далее рассмотрим одну из наиболее популярных нотаций и осно- 
ванную на ней методологию ШЕЕ1. 


3.1.4. Методология ІрЕЕ1 


Метод ШЕН1, разработанный Т. Рэмей (Т.Ватеу), основан на подхо- 
де П. Чена. В настоящее время на основе совершенствования методоло- 
гии ШЕЕ! создана ее новая версия - методология ІОЕЕІХ. ФЕЕ1Х разра- 
ботана с учетом таких требований, как простота изучения и возможность 
автоматизации. ІЮЕЕІХ-диаграммы используются рядом распространен- 
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ных САЗЕ-систем, в частности, это ЕКууш Раша МоаеПег, РеяюиЛРЕЕ, 
свободно распространяемая система ТОАР” раѓа МодеПег и ряд других. 
Сущность, как в подходе Чена, обозначается прямоугольником. Спи- 
сок атрибутов приводится внутри прямоугольника, обозначающего сущ- 
ность. Атрибуты, составляющие ключ сущности, группируются в верхней 
части прямоугольника и отделяются горизонтальной чертой. 
Связь изображается линией, проводимой между сущностью- 
родителем и дочерней сущностью точкой на конце линии у дочерней 
сущности. Дополнительно может определяться мощность связи (количе- 
ство экземпляров дочерней сущности, которое может существовать для 
каждого экземпляра сущности-родителя). В ІЮЕҒІХ могут быть выраже- 
ны следующие мощности связей: 
® каждый экземпляр сущности-родителя может иметь ноль, один или 
более связанных с ним экземпляров дочерней сущности; 

® каждый экземпляр сущности-родителя должен иметь не менее одного 
связанного с ним экземпляра дочерней сущности; 

® каждый экземпляр сущности-родителя должен иметь не более одного 
связанного с ним экземпляра дочерней сущности; 

® каждый экземпляр сущности-родителя связан с некоторым фиксиро- 
ванным числом экземпляров дочерней сущности. 

Если экземпляр дочерней сущности однозначно определяется своей 
связью с сущностью-родителем, то связь называется идентифицирующей, 
в противном случае - не- 
идентифицирующей. 

Идентифицирующая 
связь между сущностью- 
родителем и сущностью- 
потомком изображается 
сплошной линией (рис. 3.8). 
Сущность-потомок в иден- 
тифицирующей связи явля- 
ется зависимой сущностью (изображается на диаграмме прямоугольни- 
ком с закругленными концами). 

В приведенном примере Сущность? имеет составной первичный ключ 
(Ключ1, Ключ2), т.е. сущность? не имеет собственного идентификатора, а 
идентифицируется через 

первичный ключ родителя. Сущность 1 

Пунктирная линия 
изображает неидентифици- 
рующую связь (рис. 3.9). 
Сущность-потомок в не- 


идентифицирующей связи Рис. 3.9. Неидентифицирующая связь 


Сущность 2 


(Ключі (ЕЮ 
Ключа 


Рис. 3.8. Идентифицирующая связь 
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будет независимой от ключа родителя, если она не является также сущно- 
стью-потомком в какой-либо идентифицирующей связи. Неидентифици- 
рующая связь является более слабой, чем идентифицирующая, а сущ- 
ность-потомок — более независимой от родителя. 

Некоторые САЅЕ- 
системы, например ЕК- 
УМ т, позволяют изобра- 
жать на диаграмме связь 
«многие-ко-многим» В 
виде сплошной линии с 
точками на обоих концах Рис. 3.10. Связь Многие ко многим 
(рис.3.10), при этом вы- 
полняют автоматическое формирование ассоциированной сущности, ко- 
торая в физической схеме превращается в таблицу-связку. 

В заключение приведем фрагмент диаграммы «сущность-связь», 
изображенный на рис.3.6, в нотации ІЮЕҒІХ (рис.3.11). 

подразделения 


код подразделения 


наименование 
код руководителя (ЕК) 


1 


дети сотрудников сотрудники 

ИМЯ код сотрудника проекты 

код сотрудника (ЕК) ФИО код проекта 
|дата рождения код подразделения (РК) наименование 


Рис. 3.11. Фрагмент диаграммы «сущность-связь» (РЕЕ1Х) 


Здесь следует обратить внимание на связи между подразделениями и 
сотрудниками. Связь слева имеет мощность 1:М (в каждом подразделе- 
нии много сотрудников), связь справа имеет мощность 1:1 (каждый со- 
трудник может руководить не более чем одним подразделением). Но обе 
связи являются необязательными, т.е. сотрудник может не руководить 
никаким подразделением, а подразделение может какое-то время сущест- 
вовать без сотрудников. 
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3.2. Нормализация базы данных 


Диаграммы «сущность — связь» являются самым общим способом 
описания данных предметной области, который базируется только на се- 
мантическом анализе информации и не учитывает особенностей реляци- 
онной модели данных. 

Современные методологии, такие как ШЕЕ1Х, уже используют тер- 
минологию реляционных баз данных (например, понятия внешнего клю- 
ча, ассоциированной сущности и т.д.) и позволяют проектировать модель 
«сущность — связь», которая затем автоматически преобразуется в схему 
реляционной базы данных. Однако процесс выделения сущностей и ана- 
лиза связей по-прежнему остается не формализованным, а результаты 
существенно зависят от опыта и аналитических способностей проекти- 
ровщика. 

В процессе разработки основ реляционной теории был предложен 
формальный математический аппарат, позволяющий проектировать реля- 
ционные базы данных с минимальной избыточностью, который получил 
название нормализации базы данных. В настоящее время нормализация не 
рассматривается как основной аппарат проектирования БД, но является 
прекрасным средством анализа имеющейся схемы БД (например, полу- 
ченной с помощью методологии ШЕЕ!Х) с целью обнаружения и устра- 
нения избыточности данных. 

Нормализация основана на анализе функциональных зависимостей 
(ФЗ) между атрибутами отношений. Начнем с формального определения 
ФЗ и их математических свойств. 


3.2.1. Определение функциональной зависимости 


Если даны два атрибута Х и У некоторого отношения, то говорят, 
что У функционально зависит от Х, если в любой момент времени каж- 
дому значению Х соответствует ровно одно значение У. 

Функциональная зависимость обозначается Х —> У. Отметим, что Хи У 
могут представлять собой не только единичные атрибуты, но и группы (под- 
множества), составленные из нескольких атрибутов одного отношения. 

Подмножество атрибутов Х называют детерминантом функцио- 
нальной зависимости. 

Можно сказать, что функциональные зависимости представляют со- 
бой связи типа "один ко многим", существующие внутри отношения. 

Например, в отношении Сотрудники (код, ФИО, пол, да- 
та рождения) можно выделить довольно много ФЗ. Вот некоторые из них: 
е код > ФИО 
® код пол 
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® код ә дата рождения 

е код > (ФИО, дата рождения), 

поскольку каждому значению кода соответствует ровно одно значение 
атрибутов ФИО, пол и дата рождения и любых их сочетаний. Однако 
нельзя с уверенностью сказать, что каждому значению ФИО соответству- 
ет ровно одно значение кода (могут оказаться полные однофамильцы), 
поэтому нельзя говорить о наличии ФЗ ФИО - код. Тем более, не может 
быть, например, ФЗ дата рождения > ФИО. 

Атрибуты ФИО и дата рождения являются взаимно независимыми, 
поскольку в общем случае ни один из них не зависит от другого. Заметим, 
что если текущее состояние базы данных таково, что все ФИО различны, 
все равно нельзя говорить о наличии ФЗ ФИО — дата рождения, по- 
скольку уникальность и/или неизменность столбца ФИО явно не декла- 
рирована и значения-дубликаты могут появиться в любой момент. 

Стоит обратить внимание на возможность существования ФЗ ФИО 
пол. Создание программного кода, которое может автоматически без- 
ошибочно вычислять пол по заданному значению ФИО, весьма пробле- 
матично при существующем разнообразии способов формирования ФИО 
и национальных особенностях. Поэтому в существующих БД принято пол 
хранить явно и считать, что такой ФЗ в отношении нет. 


3.2.2. Математические свойства ФЗ, теоремы 


Рассмотрим некоторые математические свойства ФЗ, вытекающие из 
ее определения. Данные свойства получили название правил Армстронга 
по имени исследователя, который их сформулировал. 

1. Рефлективность 

Если У является подмножеством Х, то Х определяет У 
Усх=>Х>У 

Такая функциональная зависимость называется тривиальной. 


2. Дополнение 
А>В => АСЭВС, где С – любое подмножество атрибутов отношения. 


3. Транзитивность 
А-В и В->С => АЭС 
В этом случае говорят, что С транзитивно зависит от А. К этому 
понятию мы еще вернемся при рассмотрении третьей нормальной формы. 
Из этих трех основных свойств можно вывести еще несколько. 


4. Самоопределение 
Хх 
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Такая зависимость не несет какой-либо информации, однако она 
удовлетворяет определению ФЗ 


5. Декомпозиция 
А>ВС=>А->В, АС 


6. Композиция 
А>В и Ср =>АС>>ВО 


7. Теорема о всеобщей зависимости или теорема всеобщего объеди- 
нения 


Если АВ и СР” => А ҳС-В)эВр 

Здесь ‹/ - операция объединения множеств. 

Правила Армстронга позволяют выводить новые ФЗ на основе дру- 
гих ФЗ. Применяя их, можно вывести множество всех ФЗ данного от- 
ношения. Такое множество называется замыканием. 

И наоборот, для каждого отношения можно найти такое множество 
всех ФЗ, в котором ни одна ФЗ не может быть выведена из другой. Такое 
множество ФЗ заданного отношения называется неприводимым. 
К.Дж.Дейт показал, что неприводимое множество ФЗ должно обладать 
следующими свойствами: 

• в правой части каждой ФЗ должен быть только одни атрибут; 
е — ИЗ Левой части каждой ФЗ нельзя удалить ни одного атрибута без по- 
тери этой ФЗ 

Такое множество для каждого отношения может быть только одно. 

Возвращаясь к примеру с ФЗ отношения Сотрудники (код, ФИО, пол, 
дата рождения), отметим, что приведенное в примере множество ФЗ 
• код > ФИО 
е код пол 
® код ә дата рождения 
• код > (ФИО, пол) 
не является неприводимым, т.к. последняя ФЗ может быть легко выве- 
дена из первых двух. Первые три ФЗ составляют неприводимое множест- 
во ФЗ для отношения Сотрудники. 

Приведенное множество не является и замыканием, поскольку из 
приведенных выше ФЗ можно вывести еще много других ФЗ, например, 
(код, ФИО) > дата рождения, (код, дата рождения) > ФИО ит.д. 
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3.2.3. Процедура нормализации. Декомпозиция от- 
ношений 


Нежелательные ФЗ 


Некоторые функциональные зависимости, входящие в неприводимое 
множество ФЗ отношения, являются нежелательными, так как приводят к 
дублированию информации, что, в свою очередь, создает проблемы об- 
новления данных и представляет угрозу целостности БД. 

Например, добавим в отношение Сотрудники дополнительный атри- 
буг возрастная категория, который может принимать значения «несо- 
вершеннолетний», «пенсионер» и МОЛІ. для остальных сотрудников. До- 
бавление этого атрибута внесет новую ФЗ в неприводимое множество ФЗ: 

(дата рождения, пол) > возрастная категория 

(граница пенсионного возраста зависит от пола, поэтому в общем 
случае возрастную категорию определяют два атрибута) 

Данную ФЗ отнесем к нежелательным по двум причинам. Во- 
первых, новый столбец возрастная категория будет содержать очень 
много дублирующихся значений. Во-вторых, для поддержки актуального 
СОСТОЯНИЯ ЭТОГО атрибута придется каждый день выполнять пересчет его 
значений. Если хотя бы один день не будет выполнено такое обновление, 
база данных окажется в противоречивом состоянии. При любых законо- 
дательных изменениях возрастных границ снова придется обновлять ат- 
рибут возрастная категория для всех сотрудников. 

Правильным решением будет создание отдельного отношения, со- 
держащего всю информацию, необходимую для определения возрастной 
категории по известной дате рождения и полу сотрудника. Можно пред- 
ложить, например, такую схему отношения: 

Возрастные категории (код категории, название, пол, возрастная 
граница) 

В отношении будет всего три кортежа (по одному на каждую возрас- 
тную категорию), поэтому никакого дублирования информации не будет. 
Любые изменения возрастных границ достаточно обновить в одном месте. 

Приведенный пример пока не дает ответа на вопрос, каким образом 
удобнее выявлять нежелательные ФЗ, однако указывает путь их устране- 
ния — вынесение нежелательных ФЗ в отдельные отношения. 

Этот процесс называется декомпозицией (разбиением) имеющихся 
отношений. В процессе декомпозиции количество отношений в базе дан- 
ных увеличивается, но общее количество хранимых данных, как правило, 
сокращается за счет устранения дублирования данных. 
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Декомпозиция без потерь. Теорема Хеза 


Декомпозиция отношения есть не что иное, как взятие одной или не- 
скольких проекций исходного отношения так, чтобы эти проекции в со- 
вокупности содержали (возможно, с повторениями) все атрибуты исход- 
ного отношения. Иначе говоря, при декомпозиции не должны теряться 
атрибуты отношений. Но при декомпозиции также не должны потерять- 
ся и сами данные. Данные можно считать не потерянными в том случае, 
если по декомпозированным отношениям можно полностью восстановить 
исходное отношение в прежнем виде, используя операцию соединения 
отношений. 

Проекции В; и В отношения К называются декомпозицией без по- 
терь, если отношение А точно восстанавливается из них при помощи 
естественного соединения для любого состояния отношения К. 


Теорема Хеза 


Пусть А(А, В, С) - отношение, А, В, С - атрибуты или множества ат- 
рибутов этого отношения. Если имеется функциональная зависимость 
А > В, то проекции В. (А, В) иБ). (А, С) образуют декомпозицию без 
потерь. 

Иными словами, любую ФЗ отношения можно вынести в отдельное 
отношение, оставив ее детерминант в исходном отношении. При этом 
никакая информация не будет утеряна. 

Обратимый пошаговый процесс декомпозиции отношений с устра- 
нением нежелательных функциональных зависимостей называется нор- 
мализацией. 


3.2.4. Нормальные формы 


Процесс нормализации выполняется в несколько этапов, на каждом 
из этапов база данных приводится к очередной нормальной форме, при- 
чем каждая следующая нормальная форма обладает свойствами лучшими, 
чем предыдущая. 

Каждой нормальной форме соответствует некоторый определенный 
набор ограничений, и отношение находится в некоторой нормальной 
форме, если удовлетворяет свойственному ей набору ограничений. 

В теории реляционных баз данных обычно выделяется следующая 
последовательность нормальных форм: 

® первая нормальная форма (ПМЕ); 
вторая нормальная форма (23Р); 
третья нормальная форма (ЗМЕ); 
нормальная форма Бойса-Кодда (ВСМР); 
четвертая нормальная форма (43Р); 
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® пятая нормальная форма, или нормальная форма проекции- 

соединения (5МЕ или РИМЕ). 

Основные свойства нормальных форм: 

• каждая следующая нормальная форма в некотором смысле лучше 

предыдущей; 

® при переходе к следующей нормальной форме свойства преды- 

дущих нормальных свойств сохраняются. 

На практике обычно доводят базу данных до третьей нормальной 
формы. Подробный анализ положительных и отрицательных сторон нор- 
мализации содержится в следующей лекции. 

Рассмотрим подробнее каждый из этапов нормализации. 


Требования первой нормальной формы - 1МЕ 


Отношение находится в 1 МЕ, если оно удовлетворяет двум условиям: 

1. Значения всех его атрибутов атомарны; 

2. Отсутствуют повторяющиеся группы атрибутов. 

Первое из условий выполняется для любого отношения автоматиче- 
ски, поскольку оно следует из свойств отношений. Здесь требуется только 
уточнить понятие атомарности для текстовых атрибутов. Например, такие 
атрибуты, как ФИО или адрес сотрудника, можно считать атомарными 
только в тех случаях, когда все запросы к базе данных требуют извлече- 
ния этих атрибутов целиком, без вычленения отдельных составляющих. 

В подавляющем большинстве случаев ФИО хранится в виде трех от- 
дельных атрибутов-атомов, адрес также разбивается на несколько состав- 
ляющих, каждая из которых в рамках бизнес-правил предметной области 
является неделимым атомом. В рамках данной лекции будем считать 
ФИО атомарным атрибутом. 

Второе условие требует отдельного пояснения. Повторяющейся 
группой называют подмножество атрибутов отношения, определенных на 
одном и том же домене и имеющих одинаковую семантику. Например, 
рассмотрим отношение 

Доходы сотрудников 

(код, ФИО, доход за январь, за февраль, ...,за декабрь) 

Здесь явно видна повторяющаяся группа из 12 атрибутов, каждый из 
которых хранит доходы сотрудников за различные месяцы. Такая таблица 
удобна для формирования отчетов и справок о доходах, она не содержит 
нежелательных ФЗ, однако многие операции реляционной алгебры не 
рассчитаны на такую структуру, поэтому многие запросы будут сложно 
реализовать. В данном случае устранить повторяющуюся группу неслож- 
но, поскольку каждый из месяцев имеет известный порядковый номер. 
Изменим схему отношения: 

Доходы сотрудников (код, ФИО, номер месяца, доход) 
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Количество кортежей в новом отношении будет в 12 раз больше, чем 
в исходном, но строить произвольные запросы к такому отношению го- 
раздо удобнее. Данное отношение удовлетворяет требованиям первой 
нормальной формы. 

К сожалению, выполнив преобразование отношения, мы внесли одну 
серьезную проблему — значения атрибута ФИО будут дублироваться в 
каждом из 12 кортежей, относящихся к одному сотруднику. 

На следующем этапе нормализации эта проблема будет решена. 


Требования второй нормальной формы - 2МЕ 


Первичный ключ отношения иногда включает несколько атрибутов 
(в таком случае его называют составным). Например, отношение Дохо- 
ды сотрудников после преобразования имеет составной ключ 

(код, номер месяца). 

Введем понятие полной функциональной зависимости. 

Определение: неключевой атрибут функционально полно зависит от 
составного ключа, если он функционально зависит от всего ключа в це- 
лом, но не находится в функциональной зависимости от какого-либо 
подмножества составного ключа. 

Рассмотрим неприводимое множество функциональных зависимо- 
стей для отношения Доходы сотрудников: 

(код, месяц) > доход 

код ә ФИО 

Первая ФЗ является полной, вторая ФЗ имеет в качестве детерми- 
нанта подмножество составного ключа. Именно эта ФЗ создает дублиро- 
вание значений атрибута ФИО, поэтому является нежелательной. Дубли- 
рование информации создает и проблемы обновления: в случае необхо- 
димости изменения ФИО (допустим, сотрудник обнаружил ошибку в за- 
писи своей фамилии), исправления придется вносить 12 раз. 

Для устранения нежелательной ФЗ выполним декомпозицию в соот- 
ветствии с теоремой Хеза – выделим эту ФЗ в отдельное отношение. В 
итоге получим нормализованную структуру из двух отношений: 

Сотрудники (код, ФИО) 

Доходы сотрудников (код, номер месяца, доход) 

Для этого примера процесс нормализации завершен - ни одно из от- 
ношений больше не содержит нежелательных ФЗ. Дублирование инфор- 
мации устранено. 

Таким образом, можно дать определение второй нормальной формы: 

Отношение находится в 2МЕ, если оно находится в ІМЕ и каждый 
неключевой атрибут функционально полно зависит от ключа. 
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Требования третьей нормальной формы - ЗМЕ 


Перед обсуждением третьей нормальной формы напомним понятие 
транзитивной ФЗ, которое уже рассматривалось выше. 

Определение: Пусть Х, У, 4 - три атрибута некоторого отношения. 
При этом Х > УиУ\У 1. Тогда 2 транзитивно зависит от Х. 

Рассмотрим еше одну возможную схему отношения Сотрудники 
(код, ФИО, должность, должностной оклад). Запишем неприводимое 
множество функциональных зависимостей при условии, что должностной 
оклад сотрудника зависит только от занимаемой должности (предполо- 
жим, что это правило согласовано с представителями бизнеса): 

код > ФИО 

код должность 

должность > должностной оклад 

Получается, что должностной оклад зависит от кода сотрудника 
транзитивно, через должность. ФЗ должность — должностной оклад в 
рассматриваемом отношении является нежелательной и приводит к дуб- 
лированию значений атрибута должностной оклад. 

При этом возникают следующие проблемы обновления данных: 

• ссли в данный момент ни один из сотрудников не работает в какой- 
либо должности (например, психолог), нельзя ввести данные о соответст- 
вующем должностном окладе, 

• при изменении должностных окладов необходим просмотр всего 
отношения и изменение кортежей для всех сотрудников, которые зани- 
мают должности с изменившимся окладом. 

Для устранения этих проблем необходимо декомпозировать исход- 
ное отношение на два: 

Сотрудники (код, ФИО, должность) и 

Должности (должность, должностной оклад). 

Определение третьей нормальной формы: 

Отношение находится в ЗМЕ, если оно находится в 2МЕ и каждый 
неключевой атрибут нетранзитивно зависит от первичного ключа. 


Нормальная форма Бойса-Кодда - ВСМЕ 


Эта нормальная форма вводит дополнительное ограничение по срав- 
нению с третьей нормальной формой. 

Определение нормальной формы Бойса-Кодда: 

Отношение находится в ВСМЕ, если оно находится в ЗМЕ ив ней от- 
сутствуют зависимости атрибутов первичного ключа от неключевых ат- 
рибутов. 
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Ситуация, когда отношение находится в ЗМЕ, но не в ВСЕ, возни- 
кает при условии, что отношение имеет два (или более) возможных клю- 
ча, которые являются составными и имеют общие атрибуты. 

Заметим, что на практике такая ситуация встречается достаточно 
редко, для всех прочих отношений ЗМЕ и ВСМЕ эквивалентны. 


Требования четвертой нормальной формы - 4МЕ 


Четвертая нормальная форма касается отношений, в которых имеют- 
ся повторяющиеся наборы данных. На практике нарушения 4МЕ часто 
происходят в таблицах-связках, которые связывают более двух сущно- 
стей. В этом случае используют декомпозицию, основанную на много- 
значных зависимостях. 

Многозначная зависимость является обобщением функциональной 
зависимости. 

В качестве примера рассмотрим отношение: 

Расписание занятий (день недели, номер пары, код группы, пред- 
мет, преподаватель, аудитория), 

хранящее сведения о расписании занятий студенческих групп за не- 
делю (для упрощения считаем, что нет разбиения на подгруппы и объе- 
динения в потоки). 

В данном отношении можно выделить несколько альтернативных 
составных ключей: 

(день недели, номер_пары, код_группы), 

(день недели, номер_пары, преподаватель), 

(день недели, номер пары, аудитория). 

Некоторые атрибуты этого отношения трудно назвать абсолютно не- 
зависимыми. Однако при условии, что каждый преподаватель может вес- 
ти несколько предметов, а каждый предмет может вести несколько пре- 
подавателей, между этими атрибутами отсутствует ФЗ, соответствующая 
определению, приведенному в начале лекции. Если предположить, что 
аудитория явно не определяется ни предметом, ни группой, ни препода- 
вателем, никаких нежелательных ФЗ в отношении выделить нельзя, по- 
этому оно удовлетворяет требованиям не только ЗМЕ, но и МЕВС. 

Связь между атрибутами предмет и преподаватель можно опреде- 
лить как «многие ко многим». Между ними существует многозначная 
зависимость, которая обозначается так: 

предмет ->> преподаватель 

Аналогичная многозначная зависимость существует между атрибу- 
тами предмет и группа, поскольку каждая студенческая группа имеет 
определенный учебный план и изучает определенное заранее множество 
предметов. 
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Наличие многозначных зависимостей привносит в отношение значи- 
тельную избыточность и приводит к возникновению проблем с обновле- 
нием данных. Например, если какой-то преподаватель уволился и его ме- 
сто занял другой, то придется обновить все кортежи расписания, в кото- 
рых присутствует данный преподаватель. Кроме того, имеется опасность 
внести в расписание предмет, который не входит в учебный план группы 
или преподавателя, который не ведет данный предмет. 

Определение четвертой нормальной формы: 

Отношение находится в 4МЕ, если оно находится в ВСМЕ и в нем от- 
стутсвуют многозначные зависимости. 

В приведенном примере не так-то просто избавиться от многознач- 
ных зависимостей. Можно предложить такой вариант: 

Выносим в отдельные отношения зависимости предмет и препода- 
ватель и предмет и группа. Естественное соединение этих отношений 
даст допустимые сочетания (предмет, преподаватель, группа). 

Тогда схема отношения Расписание будет иметь вид: 

Расписание (день недели, номер пары, аудитория, код допустимого 
сочетания предмет_ преподаватель группа) 


Требования пятой нормальной формы - 5МЕ 


До сих пор мы предполагали, что единственной операцией, необхо- 
димой для устранения избыточности в отношении, была декомпозиция 
его на две проекции. Однако, существуют отношения, для которых нельзя 
ВЫПОЛНИТЬ Декомпозицию без потерь на две проекции, но которые можно 
подвергнуть декомпозиции без потерь на три (или более) проекций. Этот 
факт получил название зависимости по соединению, а такие отношения 
называют 3-декомпозируемые отношения (ясно, что любое отношение 
можно назвать "п-декомпозируемым", где п >= 2). 

Зависимость по соединению является обобщением многозначной за- 
ВИСИМОСТиИ. Отношения, в которых имеются зависимости по соединению, 
не являющиеся одновременно ни многозначными, ни функциональными, 
также характеризуются аномалиями обновления. Поэтому вводится поня- 
тие пятой нормальной формы. 

Определение пятой нормальной формы: 

Отношение находится в 5М№Е тогда и только тогда, когда любая зави- 
симость по соединению в нем определяется только его потенциальными 
ключами. 

На практике требования 5МЕ проверить достаточно сложно, а избав- 
ление от зависимостей соединения резко увеличивает число отношений в 
базе данных. В силу этих причин пятая нормальная форма представляет 
скорее теоретический интерес, чем практическую потребность. 
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3.3. Денормализация. Хранилища данных 


3.3.1. Недостатки нормализованной базы данных 


До сих пор речь шла только о недостатках ненормализованных (или 
в недостаточной мере нормализованных) баз данных, причем в качестве 
основных недостатков отмечались: 
® неэкономное использование дискового пространства ввиду наличия 
дублирующихся данных; 

® проблемы, связанные с обновлением данных ввиду нарушения фун- 
даментального принципа «Каждый факт – в одном месте»; 

® связанные с ними проблемы усиленного контроля целостности дан- 
ных, которая подвергается серьезным испытаниям при наличии дуб- 
лирующихся данных. 

Можно сделать вывод, что для динамично обновляющихся баз дан- 
ных нормализация является необходимостью, позволяющей избежать 
многих проблем в процессе функционирования ИС. 

Тем не менее, нормализация имеет один существенный недостаток - 
замедление работы СУБД при выполнении запросов на извлечение (вы- 
борку) данных. В нормализованной базе данных практически каждый 
запрос требует соединения данных нескольких таблиц (иногда в запросах 
приходится соединять и довольно много таблиц). Соединение таблиц — 
операция, требующая определенных затрат ресурсов — памяти, процес- 
сорного времени. Чем выше степень нормализованности базы данных, 
тем больше в ней таблиц, следовательно, тем медленнее выполняются 
запросы на выборку. 

В силу этих обстоятельств на практике обычно стараются найти ра- 
зумный компромисс и редко доводят нормализацию до 5МЕ. Практика 
показала, что большинство динамично обновляющихся БД обычно дово- 
дится до ЗМЕ. Во многих случаях полезно избавление от многозначных 
зависимостей (4МЕ). 

Если количество запросов на выборку существенно превышает ко- 
личество запросов на обновление, имеет смысл проанализировать воз- 
можности сознательной денормализации базы данных и поступиться даже 
требованиями ЗМЕ. 

Денормализация — это процесс модификации структуры таблиц 
нормализованной базы данных с целью повышения производительности 
за счет допущения некоторой управляемой избыточности данных. Един- 
ственным оправданием денормализации является попытка повышения 
скорости работы приложений, работающих с базой данных. 

Денормализованная база данных — это не то же самое, что ненорма- 
лизованная. Денормализация базы данных представляет собой процесс 
понижения нормализации на один-два уровня. 
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Денормализация предполагает объединение некоторых из ранее раз- 
деленных таблиц и создание таблиц с дубликатами данных с целью 
уменьшения числа связываемых таблиц при доступе к данным, что долж- 
но уменьшить число требуемых операций ввода-вывода и нагрузку на 
центральный процессор. 

Однако за денормализацию нужно платить. В денормализованной 
базе данных повышается избыточность данных, что может повысить про- 
изводительность, но потребует больше усилий для контроля ссылочной 
целостности. Усложнится процесс создания приложений, поскольку дан- 
ные будут повторяться и их труднее будет отслеживать. 

Существует золотая середина между нормализацией и денормализа- 
цией, но чтобы найти ее, требуются немалые усилия и хорошее знание 
предметной области. 

К сожалению, не существует никаких формализованных методов для 
достижения удовлетворительного компромисса между нормализацией и 
денормализацией. Некоторые соображения по этому поводу содержатся в 
следующем разделе. 


3.3.2. ОІТР и ОГАР-системы. Оаќёа Мттад 


Можно выделить некоторые классы информационных систем, для 
которых больше подходят сильно или слабо нормализованные модели 
данных. 

Сильно нормализованные модели данных хорошо подходят для так 
называемых ОГТР-систем (Оп-Гіпе Тғапѕасііоп Ргосеѕѕіпю - оперативная 
обработка транзакций). 

Типичными примерами ОГТР-систем являются системы складского 
учета, системы заказов билетов, банковские системы, выполняющие опе- 
рации по переводу денег, и т.п. Основная функция подобных систем за- 
ключается в выполнении большого количества коротких транзакций. 
Механизм транзакций будет подробно рассмотрен в лекции 16, для пони- 
мания принципов работы ОГТР-систем достаточно представлять тран- 
закцию как атомарное действие, изменяющее состояние базы данных. 

Транзакции в ОГТР-системе являются относительно простыми, на- 
пример, «снять сумму денег со счета А и добавить эту сумму на счет В». 
Проблема заключается в том, что, во-первых, транзакций очень много, во- 
вторых, выполняются они одновременно (к системе может быть подклю- 
чено несколько тысяч одновременно работающих пользователей), в- 
третьих, при возникновении ошибки, транзакция должна целиком отка- 
титься и вернуть систему к состоянию, которое было до начала транзак- 
ции (не должно быть ситуации, когда деньги сняты со счета А, но не по- 
ступили на счет В). 
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Практически все запросы к базе данных в ОГТР-приложениях состо- 
ят из команд вставки, обновления, удаления. Запросы на выборку в ос- 
новном предназначены для предоставления пользователям возможности 
выбора из различных справочников. Большая часть запросов известна 
заранее еще на этапе проектирования системы. Таким образом, критиче- 
ским для ОГТР-приложений является скорость и надежность выполнения 
коротких операций обновления данных. 

База данных, с которой работают ОГТР-приложения, постоянно об- 
новляется, в связи с этим ее обычно называют оперативной БД. Чем вы- 
ше уровень нормализации оперативной БД, тем быстрее и надежнее рабо- 
тают ОГТР-приложения. Отступления от этого правила могут происхо- 
дить тогда, когда уже на этапе разработки известны некоторые часто воз- 
никающие запросы, требующие соединения отношений и от скорости 
выполнения которых существенно зависит работа приложений. В этом 
случае можно сознательно внести некоторую избыточность в базу данных 
для ускорения выполнения подобных запросов. 

Другим типом информационных систем являются так называемые 
ОГАР-системы (Оп-Гіпе Апаійіса! Ргосезята - оперативная аналитиче- 
ская обработка данных). ОГАР используется для принятия управленче- 
ских решений, поэтому системы, использующие технологию ОГАР, на- 
зывают системами поддержки принятия решений (Песіѕіоп Зирром 
зумет - 055). 

Концепция ОГ.АР была описана в 1993 году Эдгаром Коддом, авто- 
ром реляционной модели данных. В 1995 году на основе требований, из- 
ложенных Коддом, был сформулирован так называемый тест ЕАЗМТ 
(Кая Апаіуѕіѕ оў Эйагей МиШаітепѕіопа! трюгтайоп — быстрый анализ 
разделяемой многомерной информации), включающий следующие требо- 
вания к приложениям для многомерного анализа: 

• предоставление пользователю результатов анализа за приемлемое 
время (обычно не более 5 с), пусть даже ценой менее детального ана- 
лиза; 

• возможность осуществления любого логического и статистического 
анализа, характерного для данного приложения, и его сохранения в 
доступном для конечного пользователя виде; 

® многопользовательский доступ к данным с поддержкой соответст- 
вующих механизмов блокировок и средств авторизованного доступа; 

® многомерное концептуальное представление данных, включая пол- 
ную поддержку для иерархий и множественных иерархий (это — 
ключевое требование ОГАР); 

• возможность обращаться к любой нужной информации независимо 
от ее объема и места хранения. 
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ОГАР-приложения оперируют с большими массивами данных, уже 
накопленными в оперативных базах данных ОГТР-систем, взятыми из 
электронных таблиц или из других источников данных. Такие системы 
характеризуются следующими признаками: 

• Добавление в систему новых данных происходит относительно редко 
крупными блоками (например, раз в квартал загружаются данные по 
итогам квартальных продаж из ОГТР-системы). 

® Данные, добавленные в систему, обычно никогда не удаляются и не 
изменяются. 

® Перед загрузкой данные проходят различные процедуры "очистки", 
связанные с тем, что в одну систему могут поступать данные из мно- 
гих источников, имеющих различные форматы представления, дан- 
ные могут быть некорректны, ошибочны. 

• Запросы к системе являются нерегламентированными и, как правило, 
достаточно сложными. Очень часто новый запрос формулируется 
аналитиком для уточнения результата, полученного в результате пре- 
дыдушего запроса. 

® Скорость выполнения запросов важна, но не критична. 

Исходя из перечисленных признаков ОГ.АР-систем, можно сделать 
вывод, что база данных такой системы может быть в значительной степе- 
ни денормализованной. Поскольку основным видом запросов к базе дан- 
ных являются запросы на выборку, положительные моменты нормализа- 
ции не могут быть использованы, а сокращение операций соединения в 
запросах окажется весьма полезным. 

В последнее время активно развивается еще одно направление ана- 
литической обработки данных, получившее название Паѓа Мите (ос- 
мысление данных, иногда говорят «раскопка данных»). Это направление 
направлено на поиск скрытых закономерностей в данных и решение задач 
прогнозирования. Приложения раќа Мише также не изменяют данные, с 
которыми они работают, поэтому для них более предпочтительной явля- 
ется денормализованная база данных. 

Для того чтобы подчеркнуть особый способ организации данных, кото- 
рые могут эффективно использоваться для анализа приложениями ОГАР и 
Рая Мио, к ним применяют специальный термин «хранилища данных» 
(жиаЙ’аге Поиѕе). Важно отметить, что хранилища данных, в отличие от 
оперативной БД, хранят исторические данные, т.е. отражают те факты из 
деятельности предприятия, которые уже произошли, следовательно, могут 
храниться в неизменном виде («историю не переписывают») и накапливаться 
годами, в связи с чем их размеры могут стать весьма внушительными. После 
перекачки данных в хранилище они обычно удаляются из оперативной БД, 
что позволяет поддерживать ее размеры в заданных пределах. 

Таким образом, можно представить корпоративную информацион- 
ную систему современного предприятия в виде совокупности нескольких 
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различных подсистем, среди которых есть ОГТР, ОГ.АР-системы, а также 


приложения Даа Міпіпо (рис 3.12). 
ОТАР - раѓа 
приложения Міпіпа 


хранилище 
данных 


очистка данных 


оперативная оперативная 


ОІТР - приложения ОТР - приложения 


Рис. 3.12. Интегрированная 
информационная система предприятия 


Корпоративные данные могут собираться в одной или нескольких 
оперативных БД, а все исторические данные концентрируются в едином 
хранилище, которое объединяет все данные в целях выполнения различ- 
ных видов их анализа и предоставления управленческому персоналу ин- 
формации, необходимой для принятия обоснованных решений по управ- 
лению бизнесом. 


3.3.3. Хранилища данных 


Ральф Кимбалл (Каф КітбаП), один из авторов концепции храни- 
лищ данных, описывал хранилище данных как «место, где люди могут 
получить доступ к своим данным». Он же сформулировал и основные 
требования к хранилищам данных: 

® поддержка высокой скорости получения данных из хранилища; 

® поддержка внутренней непротиворечивости данных; 

е возможность получения и сравнения так называемых срезов дан- 

ных (5ісе апа дісе); 
наличие удобных утилит просмотра данных в хранилише; 
полнота и достоверность хранимых данных; 

® поддержка качественного процесса пополнения данных. 
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Типичная структура хранилищ данных 


В отличие от оперативных баз данных, хранилища данных проекти- 
руются таким образом, чтобы время выполнения запросов на выборку 
данных было минимальным. Обычно данные копируются в хранилище из 
оперативных баз данных согласно определенному расписанию (раз в 
день, раз в месяц, раз в квартал). 

Типичная структура хранилища данных существенно отличается от 
структуры обычной реляционной БД. Как правило, эта структура денор- 
мализована (это позволяет повысить скорость выполнения запросов), по- 
этому может допускать избыточность данных. 

Логически структуру хранилища данных можно представить как мно- 
гомерную базу данных, которая представляет собой так называемый ОГАР- 
куб. ОГАР-куб имеет несколько измерений, которые можно считать осями 
координат (если таких измерений три, то тогда уместна геометрическая 
интерпретация в виде куба, на практике обычно бывает более трех измере- 
ний, которые не отобразить никакой геометрической фигурой). На пересе- 
чении осей располагаются показатели (один или несколько – как получит- 
ся), они и являются предметом многомерного анализа. 

Основной операцией, применяемой к ОГАР-кубам, является опера- 
ция агрегирования показателей (т.е. вычисления агрегатных функций, 
таких как сумма, минимальное, максимальное, среднее значение показа- 
теля) применительно к различным измерениям. Например, можно вычис- 
лить суммарные объемы продаж за различные периоды времени, по от- 
дельным группам товаров, по различным регионам и т.д. 


таблица таблица 
размерности размерности 
1 4 


таблица 
фактов 


таблица таблица 
размерности размерности 
2 5 


таблица 
размерности 
з 


Рис. 3.13. Типичная структура хранилища данных — схема «звезда» 


Реализация ОГ.АР-кубов может быть различной. В последнее время 
наиболее распространенным вариантом является использование денорма- 
лизованной реляционной структуры. В этом случае основными состав- 
ляющими структуры хранилищ данных (рис.3.13) являются таблица фак- 
тов (Ѓасі ‹аЫе) и таблицы измерений (йітепѕіоп {а 1$), соединенные по 
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схеме «звезда» (5аг ѕсһета). Название «звезда» используется в том слу- 
чае, если каждое измерение содержится в одной таблице размерности. 


Таблица фактов 


Таблица фактов является основной таблицей хранилища данных. Как 
правило, она содержит сведения об объектах или событиях, совокупность 
которых будет в дальнейшем анализироваться. Обычно говорят о четырех 
наиболее часто встречающихся типах фактов. К ним относятся: 

» факты, связанные с транзакциями (Тгапзасйоп Ғасіѕ). Они основаны 
на отдельных событиях (типичными примерами которых являются 
телефонный звонок или снятие денег со счета с помощью банкомата); 

• факты, связанные с «моментальными снимками» (ЗпарзПое Ғасіѕ). Ос- 
нованы на состоянии объекта (например, банковского счета) в опре- 
деленные моменты времени, например на конец дня или месяца. Ти- 
пичными примерами таких фактов являются объем продаж за день 
или дневная выручка; 

е факты, связанные с элементами документа (Глпе-Цета Ғасіѕ). Основа- 
ны на том или ином документе (например, счете за товар или услуги) 
и содержат подробную информацию об элементах этого документа 
(например, количестве, цене, проценте скидки); 

• факты, связанные с событиями или состоянием объекта (Еуепё ог за 
Ғасіѕ). Представляют возникновение события без подробностей о нем 
(например, просто факт продажи или факт отсутствия таковой без 
иных подробностей). 

Таблица фактов, как правило, содержит уникальный составной 
ключ, объединяющий первичные ключи таблиц измерений. Чаще всего 
это целочисленные значения либо значения типа «дата/время». Таблица 
фактов может содержать сотни тысяч или даже миллионы записей, и хра- 
нить в ней повторяющиеся текстовые описания, как правило, невыгодно — 
лучше поместить их в меньшие по объему таблицы измерений. При этом 
как ключевые, так и некоторые неключевые поля должны соответство- 
вать измерениям ОГАР-куба. Помимо этого таблица фактов содержит 
одно или несколько числовых полей для хранения показателей, на осно- 
вании которых в дальнейшем будут получены агрегатные данные. 

Отметим, что для многомерного анализа пригодны таблицы фактов, 
содержащие как можно более подробные данные (то есть данные, соответ- 
ствующие самой детальной таблице оперативной БД). Например, в банков- 
ской системе в качестве факта можно принять одну транзакцию клиента 
(снять деньги со счета, положить, перевести на другой счет и т.д.). В систе- 
ме предприятия, работающего в сфере торговли или услуг, фактом может 
быть каждая продажа или каждая услуга, оказанная клиенту. 
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Таблицы измерений 


Таблицы измерений содержат неизменяемые либо редко изменяемые 
данные. Таблицы измерений содержат как минимум одно описательное 
поле (обычно с именем члена измерения) и, как правило, целочисленное 
ключевое поле (обычно это суррогатный ключ) для однозначной иденти- 
фикации члена измерения. Нередко таблицы измерений содержат некото- 
рые дополнительные атрибуты членов измерений, содержавшиеся в исход- 
ной оперативной базе данных (например, адреса и телефоны клиентов). 

Каждая таблица измерений должна находиться в отношении один ко 
многим с таблицей фактов. 

Очень многие измерения могут представлять собой иерархию. На- 
пример, если вычислять агрегатные данные продаж по регионам, то мож- 
но выделить уровни отдельных населенных пунктов, областей, округов. 
стран, которые представляют собой иерархию. Для представления иерар- 
хии в реляционной БД может использоваться несколько таблиц, связан- 
ных отношением один ко многим и соответствующих различным уров- 
ням иерархии в измерении, или одна таблица с внутренними иерархиче- 
скими связями. 

Если хотя бы одно из измерений содержится в нескольких связанных 
таблицах, такая схема хранилища данных носит название «снежинка» 
(ѕпоууйаке ѕсһета). Дополнительные таблицы измерений в такой схеме, 
обычно соответствующие верхним уровням иерархии измерения и находя- 
щиеся в соотношении «один ко многим» с таблицей измерений, соответст- 
вующей нижнему уровню иерархии, иногда называют консольными табли- 
цами (оџігісрег (а Ме). Схема «снежинка» изображена на рис. 3.14. 
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Рис. 3.14. Структура хранилища данных — схема «снежинка» 
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Если измерение, содержащее иерархию, основано на одной таблице 
измерений, то она должна содержать столбец, указывающий на «родите- 
ля» данного члена в этой иерархии. Например, населенный пункт в каче- 
стве родителя имеет область, область — округ, округ – страну, а у страны в 
качестве родителя обычно устанавливается какое-либо значение по умол- 
чанию, соответствующее отсутствию родителя. Отметим, что скорость 
роста таблиц измерений должна быть незначительной по сравнению со 
скоростью роста таблицы фактов; например, добавление новой записи в 
таблицу измерений, характеризующую товары, производится только при 
появлении нового товара, не продававшегося ранее. 

Одно измерение куба может содержаться как в одной таблице (в том 
числе и при наличии нескольких уровней иерархии), так и в нескольких 
связанных таблицах. 

Отметим, что даже при наличии иерархических измерений с целью 
повышения скорости выполнения запросов к хранилищу данных нередко 
предпочтение отдается схеме «звезда». 


Принципы организации хранилища 


1. Проблемно-предметная ориентация: данные объединяются в кате- 
гории и хранятся в соответствии с областями, которые они описывают, а 
не с приложениями, которые они используют. 

2. Интегрированность: объединяет данные т.о., чтобы они удовле- 
творяли всем требованиям всего предприятия, а не единственной функ- 
ции бизнеса. 

3. Некорректируемость: данные в хранилище данных не создаются, 
т.е. поступают из внешних источников, не корректируются, не удаляются. 

4. Зависимость от времени: данные в хранилище точны и корректны 
только в том случае, когда они привязаны к некоторому промежутку или 
моменту времени. 


72 


4. Язык $01 


Цель изучения данной главы -— получить компетенции использования 
языка 801. (языков РОГ, и ОМІ) при разработке и эксплуатации инфор- 
мационных систем. 
После изучения главы вы будете: 
® знать команды ОПГ, уметь ими пользоваться 
® знать основные объекты реляционной базы данных (таблицы, индек- 
сы, представления, хранимые процедуры и функции, триггеры) и ис- 
пользовать их по назначению в процессе разработки приложений баз 
данных 

• уметь грамотно определять типы полей и ограничения целостности в 
процессе создания и изменения структуры таблиц 

® понимать логику разработки запросов к базам данных, свободно ис- 
пользовать команды языка ОМІ. 

® уметь пользоваться представлениями (создавать, удалять, изменять) 

• уметь создавать хранимые процедуры, функции и триггеры, исполь- 
зуя одно из процедурных расширений языка $01 (РГ./ЗОГ.) 


Введение в $01 


Первые языки запросов для реляционных баз данных пояились в 70- 

е годы. В то время существовало несколько различных языков запросов, 

что порождало определенные неудобства у производителей СУБД. Непо- 

средственным предшественником языка 501. явился язык ЗЕООЕГ.. 
Стандарт языка ЗОГ, постоянно расширяется, поэтому к настоящему 
времени имеется несколько официально утвержденных вариантов: 

1. 801-89, первый неполный вариант, практика быстро показала, что он 
нуждается в расширении. 

2. 801-92 (или 801-2), значительно расширенная версия, многие СУБД 

в настоящее время гарантируют полную поддержку ЗОГ-2 и частич- 

ную - более поздних стандартов. 

ЗОГ--99, введены еще некоторые расширения. 

4. 8501-2003, самый полный вариант стандарта, в котором учтены мно- 
гие решения, уже реализованные разработчиками СУБД и ставшие 
стандартом 4е-Ёс®ю (например, стандартизирован объект ѕедиепсе, 
который давно используется в некоторых СУБД, например, ОгасІе, 
стандартизированы почти все встроенные типы данных, используе- 
мые в различных СУБД). 

Стандарт 501-2003 содержит довольно много команд, которые ох- 

ватывают различные аспекты функционирования ИС и разделены на 7 

классов команд. Тем не менее, основу языка ЗОГ, составляют два класса 


> 
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команд, которые принято называть языками: язык определения данных и 
язык манипулирования данными. В оригинале - ОРГ, (даа дейшвоп 1ап- 
2аге) и МГ (даа ташри]аноп Іапоџағе). 

В данном учебном модуле рассмотрим только эти два класса (Ор. и 
БМП). Остальные классы, которые в стандарте 501-92 объединены об- 
щим названием «язык управления доступом» (ӣаќа сопіто! Іапеџаре – 
Рс), будут частично рассмотрены в следующем учебном модуле. 

При изложении материала будем ориентироваться на стандарт ЗОГ- 
2003, однако следует иметь в виду, что те команды, которые нам пред- 
стоит изучить, практически не изменились со времен 501-92. 

Производители СУБД, в целом поддерживая стандарт ЗОГ, тем не 
менее, иногда допускают незначительные изменения синтаксиса в от- 
дельных командах. Практически все СУБД содержат те или иные расши- 
рения языка 8501. Поэтому изучать язык ЗОГ, не привязываясь ни к ка- 
кой конкретной СУБД, можно только чисто теоретически. Поскольку це- 
лью данного модуля является получение компетенций (т.е. умения при- 
менить полученные знания на практике), необходимо остановиться на 
какой-либо конкретной СУБД, которая будет использоваться для отладки 
демонстрационных примеров и практических заданий модуля. 

В качестве такой СУБД была выбрана самая распространенная на 
мировом рынке Огабе. В диалекте 501. для СУБД ОгасІе отклонения от 
стандарта минимальны. Приведенные в главе примеры отлаживались с 
использованием клиентской консольной утилиты ЗОГ, *РІџѕ на сервере 
Отасе 102. 

Везде в описании команд, где имеется хотя бы небольшое отклоне- 
ние синтаксиса Огас!е от стандарта ЗОГ, 2003, это будет отдельно огова- 
риваться. Учитывая широкое распространение таких СУБД как М!сго5ой 
ЗОГ, Бегуег, МУЗОГ, и ряда других, иногда будут оговариваться особенно- 
сти и этих СУБД. 

Формат записи операторов 801. свободный. Везде, где имеется про- 
бел или знак препинания, может быть вставлено любое число пробелов 
или переходов на новую строку. При работе в консольной утилите 501. 
*Р1а5 используется символ ; (точка с запятой) как признак окончания за- 
проса – текст запроса, завершенный точкой с запятой, немедленно отсы- 
лается на сервер для выполнения. Однако точка с запятой не является 
частью команды ЗОГ, поэтому в приводимых в лекциях примерах она 
будет отсутствовать. 

При описании языка мы сочли возможным не приводить ПОЛНЫЙ 
синтаксис каждой команды в формальной форме (формы Бэкуса-Наура 
или синтаксические диаграммы), учитывая лаконичность и относитель- 
ную простоту синтаксиса, а также наличие отклонений от стандарта в 
диалектах языка и изменчивость самого стандарта и диалектов. Синтак- 


74 


сис команд описывается неформально, с пропуском некоторых незначи- 

тельных, с нашей точки зрения, конструкций, но достаточно строго: 

® все ключевые слова языка записываются прописными буквами, а 
имена, формируемые пользователями, - строчными, хотя, с точки 
зрения лексики языка ЗОГ, различия в регистре символов несущест- 
венны; 

• все необязательные элементы команды заключаются в квадратные 
скобки; 

® в тех случаях, где пробел может трактоваться неоднозначно, он заме- 
няется знаком подчеркивания, 

4 при пропуске части команды используется многоточие. 

Возможные недостатки неформального подхода к описанию компен- 
сируются большим количеством примеров и дополнительными словес- 
ными комментариями. 

Некоторые локализованные версии СУБД допускают использование 
в именах, формируемых пользователями, символов национальных алфа- 
витов, но рекомендуем применять эту возможность с чрезвычайной осто- 
рожностью. Ключевые символы языка не могут использоваться в качест- 
ве имен (таблиц, столбцов, представлений и т.д.) – большая часть подоб- 
ных ошибок выявляется при компиляции, но в редких случаях ошибки 
могут быть непредсказуемыми, особенно в части применения символов 
национальных алфавитов. 


4.1. Язык Юрі. Основные объекты базы данных 


Язык Ррі (Рая Оейлііоп Гапрџаре) служит для создания, удаления 
и модификации всех объектов, входящих в состав базы данных. 


4.1.1. Общий вид команд Орь 


Язык ОПТ, содержит всего три команды СКЕАТЕ, АІТЕК и ВОР, ко- 
торые могут быть применены к различным объектам базы данных. 
В самом общем виде команду РОГ, можно определить так: 


Создание (СВЕАТЕ) 


или 
Изменение (АГТЕВ) \ объект [дополн. параметры] 


или 
Удаление(рКоОР) 
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Примеры: 

ОКОР ТАВІЕ { - удаление таблицы с именем %, здесь объектом яв- 
ляется ТАВГЕ, его имя (. 

Данная команда не требует никаких дополнительных параметров 
СВЕАТЕ ТАВГЕ # (п МОМВЕВК, х УАВСНАВ(50)) – создание таблицы с 
именем її, в качестве дополнительных параметров задаются определения 
столбцов, в данном прмере их два: столбец п имеет цифровой тип, а стол- 


бец х - текстовый тип, причем длина текста не превышает 50 символов. 


4.1.2. Основные объекты БД 


Современные базы данных, кроме таблиц с данными, содержат еще 
ряд объектов, необходимых для осуществления эффективного доступа и 
обработки данных. Кратко охарактеризуем каждый из объектов. 

1. База данных (ПАТАВАЅЕ) – контейнер, в котором будут содер- 
жаться таблицы и другие объекты, которые мы рассмотрим ниже. Как 
правило, СУБД может обслуживать одновременно несколько различных 
баз данных, если в этом есть необходимость. В СУБД ОгасІе в процессе 
ее установки создается база данных, которая при работе может быть ис- 
пользована по умолчанию, поэтому во многих случаях нет необходимо- 
сти создавать другие базы данных. 

2. Схема (5СНЕМА) - часть базы данных, в пределах которой все 
имена создаваемых объектов ДОЛЖНЫ быть уникальны. В разных схемах 
одной и той же базы данных разрешены одинаковые имена, например, 
таблиц. Схемы поддерживаются далеко не всеми СУБД. СУБД Огасе 
поддерживает это понятие по-своему. Отдельной команды СКЕАТЕ 
ЭСНЕМА ... в этой СУБД нет, но при создании нового пользователя ему 
предоставляется в распоряжение собственная схема, имя которой совпа- 
дает с именем пользователя. Если пользователь наделен правами созда- 
вать объекты в базе данных, владея схемой, он будет владеть всеми пра- 
вами на те объекты, которые создаст в своей схеме. Эта тема будет под- 
робно рассматриваться в последнем учебном модуле курса. 

3. Таблица (ТАВГЕ) - безусловно, основной объект базы данных. В 
стандарте ЗОГ, таблица определяется как мультимножество строк, в отли- 
чие от реляционной теории, где отношение (математическая модель таб- 
лицы) определяется как множество кортежей (кортеж - математическая 
модель одной строки). Мультимножество является расширением понятия 
множества, в котором допускаются повторяющиеся элементы. 

Иными словами, стандарт ЗОГ, допускает создание таблицы, в кото- 
рой не определено ни одного потенциального ключа (т.е. могут быть оди- 
наковые строки). Однако на практике принято определять первичный 
ключ даже для таких таблиц, на которые не ссылаются другие таблицы. 
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4. Индекс (ТМРЕХ) – вспомогательный объект, который служит для 
ускорения поиска данных, однако замедляет операции вставки, удаления 
и обновления строк таблиц. В качестве структуры данных при реализации 
индексов, как правило, используются сильноветвящиеся деревья во 
внешней памяти (В-- деревья), которые автоматически обновляются при 
изменении данных таблицы. Кроме древовидных индексов, многие 
СУБД предоставляют возможность создавать индексы и на основе других 
структур (хеш-таблицы, битовые карты и др.). 

Для всех потенциальных ключей таблицы автоматически создаются 
древовидные индексы, по остальным столбцам можно создавать индексы 
при помощи команды СКЕАТЕ ІЧРЕХ ... . Можно создавать индексы и 
по нескольким столбцам одновременно, некоторые СУБД позволяют соз- 
давать индексы на основе выражений. 

Команда СВЕАТЕ ІЧРЕХ ... не входит в стандарт 501, 2003, однако 
поддерживается всеми СУБД без исключения. Наличие или отсутствие 
индексов сильно влияет на производительность СУБД, поэтому индексы 
по праву считаются очень важным, хотя и скрытым от пользователя, объ- 
ектом БД, требующим пристального внимания разработчиков приложе- 
ний баз данных и АБД. 

5. Представление (МІЕ№) – именованный запрос на выборку, кото- 
рый хранится в БД и выполняется на сервере при любом обращении к 
нему по имени, создавая при этом виртуальную таблицу с отобранными 
данными. Представления позволяют предоставлять пользователям любые 
выборки данных, с которыми можно работать практически так же, как и с 
физическими таблицами, входящими в состав БД. Иными словами, меха- 
низм представлений позволяет конструировать производные виртуальные 
таблицы на основе базовых таблиц базы данных. 

6. Хранимая процедура или функция (ЗТОКЕР РВОСЕРОВЕ, 
ЕОМСТІОМ№). Данные объекты БД пишутся на языке процедурного рас- 
ширения языка ЗОГ, который дополняет язык ЗОГ, такими управляющи- 
ми структурами языка высокого уровня, как ветвления и циклы, и позво- 
ляет реализовать любые алгоритмы обработки данных. Хранимый код 
постоянно хранится на сервере и выполняется по запросу на его запуск из 
приложений клиентов. 

Управляющие конструкции процедурных расширений ЗОГ, не рег- 
ламентируются стандартом, поэтому большинство СУБД имеют свои 
собственные процедурные расширения. Однако команды СВЕАТЕ РКО- 
СЕРОВКЕ ... и СВЕАТЕ ЕОМСТІОМ ... являются частью стандарта, кото- 
рый регламентирует также правила встраивания команд 801. в код хра- 
нимой подпрограммы (определяется понятие Етбедӣеа 501, – встроен- 
ный 801). 
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7. Триггер (СГЕТООЕВ) – особый вид хранимой процедуры, который 
срабатывает автоматически при наступлении определенных событий в 
базе данных. Основными такими событиями являются вставка, удаление 
и обновление строк, однако некотороые СУБД предоставляют возмож- 
ность создавать триггеры и на другие события, например, открытие и за- 
крытие сеанса связи с сервером, ряд команд ОПГ. и т.д. Триггеры – это 
очень мощный (и опасный) инструмент в руках администратора базы 
данных (о существовании триггера может не знать даже разработчик при- 
кладного ПО, не говоря уж о конечных пользователях). 

В качестве дополнительной информации перечислим еще ряд объек- 
тов базы данных, которые позволяют СУБД реализовать несколько важ- 
ных функций управления данными. 

8. Последовательность (ЗЕОЦЕМСЕ) - в некоторых СУБД (Огасіе) 
служат для генерации уникальных значений суррогатных первичных 
ключей таблиц. Присвоение этих значений ключевому столбцу в Огасе 
выполняется в триггере на вставку новой строки. 

9. Пользователь и роль (ОЗЕК, КОГЕ) – пользователи и их права на 
выполнение различных действий в базе данных. Эти объекты служат для 
разграничения доступа к информации многочисленным пользователям 
БД, которые совместно используют общие объекты базы данных и могут 
выполнять только те действия, которые определяются их ролями. 

10. Связь, снимок, синоним (ИМК, ЭМАРЬНОТ, ЅҮМОМҮМ) – данные 
объекты используются при организации распределенных баз данных, в 
которых данные хранятся на нескольких серверах (узлах), обычно уда- 
ленных друг от друга территориально. Для того, чтобы физически рас- 
пределенные данные, логически воспринимались пользователями как 
единая целостная база данных, между серверами устанавлявают связи 
(«линки»- объект ЦМК), а для удобного обращения к удаленным объек- 
там используют короткие синонимы (объект ЗУМОМУМ) вместо длин- 
ных составных имен. 

Снимок (объект ЭМАРЬНОТ) – таблица или представление, которое 
посылается на удаленный сервер и периодически обновляется в автома- 
тическом режиме. Снимок, в отличие от представления, это реальная фи- 
зическая таблица, хранящаяся на удаленном сервере, которая позволяет 
избежать многочисленных запросов пользователей удаленного сервера к 
данным, хранящимся на другом сервере. Однако не стоит забывать, что 
снимок не может обновляться очень часто, поэтому в какие-то моменты 
времени его данные могут не соответствовать актуальному состоянию 
удаленной БД. 
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Любая база данных должна содержать, как минимум, одну таблицу, 
реальные базы обычно содержат десятки, сотни и даже тысячи таблиц. 
Все остальные объекты создаются по мере необходимости. 


4.2. Команды Юрі для работы с таблицами 


4.2.1. Создание таблицы 


При создании таблицы задается ее уникальное имя и структура, т.е. 
первоначально создается пустая таблица, которая затем наполняется дан- 
ными и при помощи команд ОМІ. При определении структуры таблицы 
задаются не только имена и типы каждого столбца, но и ряд ограничений 
на вводимые данные, которые будут жестко контролироваться СУБД при 
заполнении таблиц и редактировании данных. Тем самым пользователи 
СУБД имеют возможность ограничить множество значений для встроен- 
ных типов данных СУБД, добавив дополнительные условия проверки. 
Таким образом в СУБД реализуется понятие домена как множества до- 
пустимых значений столбца. 

Следует заметить, что в стандарте БОГ. 2003 добавлена команда 
СВЕАТЕ ТУРЕ, которая позволяет определять пользовательские типы 
данных, однако для большинства стандартных областей применений баз 
данных хватает и встроенных типов с дополнительными ограничениями. 
Общий вид команды для создания таблицы: 


СВЕАТЕ ТАВІЕ имя таблицы 
(список определений столбцов [список ограничений на таблицу] 


) 


Элементы списка всегда разделяются запятыми (в дальнейшем это 
будет считаться само собой разумеющимся и особо оговариваться не бу- 
дет). 

Определение каждого столбца в списке имеет вид: 
имя столбца тип столбца [рЕЕАСІТ значение по умолчанию] [ог- 
раничения_на столбец] 

Обязательными элементами описания столбца являются имя столбца 
и тип данных в столбце. 

Имя столбца должно быть уникальным в пределах таблицы. 

Стандартом ЗОГ, предусматривается набор основных типов данных. 
Внутреннее представление и ограничения на размер типов стандартом не 
устанавливаются, они по-разному реализуются в разных СУБД. Не все 
СУБД в полном объеме реализуют стандартные типы данных, кроме того, 
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различные СУБД могут иметь собственные типы данных. Ниже мы при- 
водим стандартные типы данных ЗОГ, 2003 и основные типы данных, 
поддерживаемые СУБД Отасе. 

При определении столбца для него может быть задано значение по умол- 
чанию (РЕЕАОГТ). Если при занесении данных в строку таблицы не ука- 
зывается значение для этого столбца, в столбец заносится значение по 
умолчанию. Если значение по умолчанию для какого-либо столбца при 
создании таблицы не задается, в случае отсутствия данных элемент этого 
столбца получает значение МОТЛ.. 


Типы данных 
Числовые типы 


Стандарт предусматривает следующие числовые типы. 

ЗМАЬЬТМТ, ТМТЕСЕВ (ПМТ) и ВІСІМТ (последний появился только в 
ЗОГ 2003) - целые двоичные числа со знаком, хотя стандарт не оговари- 
вает размеры, в большинстве случаев это 2, 4 и 8 байт соответственно. 
МОМЕВТС (р, $) или МОМВЕК(р,$) или РЕСТМАТ(р,5) - типы- 
синонимы для десятичных чисел с фиксированной точкой. Число р задает 
общее количество десятичных разрядов в числе, з - число разрядов после 
точки. 

ЕІОАТ (р), ВЕА1І, РООВЬЕ РВЕСТЗТОМ - двоичные числа с плавающей 
точкой. Разрядность типов ВЕАТ и РООВЬЕ РВЕСТЗТОМ зависит от реа- 
лизации. 

В ОгасЕ, в отличие от большинства других СУБД, внутреннее пред- 
ставление всех числовых данных одинаково – все числа хранятся в дво- 
ично-десятичном представлении (т.е. для каждой десятичной цифры чис- 
ла хранится ее четырехбитное двоичное представление). Поэтому в Огасе 
имеется единственный числовой тип. 

МОМВЕВ[(р[, 5] ) ] 

Ога е однако принимает и все стандартные числовые типы и авто- 
матически переводит их во внутреннее представление МОМВЕВ. Напри- 
мер, стандартный тип ПУТЕСЕВ она автоматически приводит к типу 
МОМВЕК(38) – число без десятичной точки из 38 десятичных разрядов 
(один из них – знак числа) и отводит под него 38 байт, что в большинстве 
случаев избыточно. В целях рационального использования дискового 
пространства при работе с ОгасІе разумно пользоваться типом МОМВЕВ. 
Например, для целых чисел (соответствующих типу ПУТЕСЕК) разумным 
типом будет МИМВЕК(10). 

Вообще, для любой СУБД необходимо сначала внимательно изучить 
документацию по поддерживаемым типам и способам их внутреннего 
представления, а затем приступать к созданию таблиц. Знание внутренне- 
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го представления данных поможет не только сэкономить пространство на 
диске, но и повысить производительность СУБД за счет ускорения опе- 
раций обмена между внешней и оперативной памятью. 

Константы числовых типов записываются так же, как и десятичные 
константы в большинстве языков программирования. Для действитель- 
ных констант возможна нотация как с десятичной точкой, так и в Е- 


форме. 


Символьные типы 


СНАВ[АСТЕК] [(размер)] строка фиксированной длины (по умолчанию 
размер типа – 1 байт), максимальный размер в Огасе 2000 байт, но во 
многих СУБД размер этого типа ограничивается 256 байтами. 
УАВСНАЕ(размер) (в ОгасІе дополнительно поддерживается тип УАВ- 
СНАЕК2, идентичный УАКСНАЋК, но гарантированно неизменный вне 
зависимости от возможного изменения типа УАВСНАВ в стандарте) — 
строка переменной длины, в ОтасІе его размер не более 4000 байт. 

Данные типов СНАК и УАВСНАВ хранятся по-разному. Под СНАВ 
всегда отводится столько байт, сколько указано в размере, а под данные 
типа УАКСНАБК память на диске выделяется в соответствии с реальными 
размерами текста (все завершающие текст пробелы автоматически уда- 
ляются) плюс четыре байта для хранения этого размера. Пустая строка 
занимает 4 байта и содержит размер 0. В связи с этим для хранения таких 
данных, как наименования каких-либо объектов, предпочтительнее тип 
УАКСНАВК. Если предполагается, что столбец может содержать много 
МОИ -значений (например, столбец «Примечания» или «Пояснения»), то 
тип УАКСНАБК также выигрывает перед типом СНАК. 

Стандартом также поддерживаются типы МСНАК (МАТЮМАГ СНА- 
КАСТЕВ) и МУАВСНАК, которые были введены для поддержки симво- 
лов национальных алфавитов. Оба типа реализованы в Огасе и исполь- 
зуются в том случае, если для кодирования символов используется Оп- 
сое. 

Константы символьного типа берутся в апострофы. Апостроф внутри 
символьной константы кодируется двумя апострофами. 


Типы даты и времени 


Стандарт поддерживает типы РАТЕ, ТІМЕ и ТІМЕЅТАМР, в Огасе 
реализован тип РАТЕ, которые служит для хранения даты и времени су- 
ток, а, начиная с версии 91, еще и ТІМЕЅТАМР, который позволяет хра- 
нить момент времени с высокой точностью (до миллисекунд). 

Над датами выполняется операция вычитания, при этом разность 
двух дат вычисляется в днях. К дате можно прибавить или вычесть задан- 
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ное количество дней, при этом получается другая дата, можно сравнивать 
две даты, используя обычные знаки сравнения. Внутренний формат пред- 
ставления типа Рае в Огасіе — действительное число, целая часть которо- 
го хранит количество дней, содержащихся в дате, а действительная — 
время суток. 

Константы типа даты заключаются в апострофы, как и текстовые 
константы, их формат должен соответствовать настройкам сервера. 


Типы для хранения больших объектов 


Современные базы данных позволяют хранить не только хорошо 
структурированную фактографическую информацию, но и такие данные, 
как рисунки (фотографии). звуковые или анимационные файлы, тексты 
формата Місгоѕой Мога, \!еБ-страницы в формате Ви и другую слабо 
структурированную информацию. Для хранения подобных данных ис- 
пользуются типы больших объектов. 

Стандарт поддерживает типы ВГОВ (Вшагу Гагре Објесі) и СГОВ 
(Свагацег агре ОБес0 или МСГОВ (МаНопа! Сћагасіег Гагре Објесі). 

ОгасІе дополнительно поддерживает тип ОМ№С для хранения боль- 
ших текстов. Работа с типами ОМ№С и СГОВ выполняется значительно 
медленнее, чем с типом УАВСНАК, поэтому они используются только 
для действительно больших текстов. 

Следует заметить, что, начиная с версии 8, в Огасе появилось спе- 
циальное расширение ОгасІе Тех, предназначенное для эффективной ра- 
боты с большими текстами. 


Ограничения 


Ограничения (сопѕігаіпіѕ) позволяют задавать дополнительные усло- 
вия проверки вводимых данных, которые СУБД проверяет автоматиче- 
ски. Данные, которые не удовлетворяют условиям, заданным в ограниче- 
ниях, отвергаются. Например, при вставке новой строки в таблицу она не 
будет добавлена, если хотя бы одно из значений не удовлетворяет огра- 
ничениям. Механизм ограничений позволяет поддерживать данные в не- 
противоречивом состоянии, соответствующем бизнес-правилам предмет- 
ной области. 

Любое ограничение может быть поименовано, в противном случае, 
имя для ограничения СУБД создает автоматически. Для явного задания 
имени, к описанию ограничения следует добавить слева фразу СОМ- 
ЭТКАПМУТ имя ограничения (рекомендуется задавать явные имена для 
ограничений). 

Можно задать ограничения для отдельного столбца или для таблицы 
в целом. 
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Ограничения столбца: 


МОТ МОИМ, – допустимы ли пустые (неопределенные) значения в 
столбце, по умолчанию используется значение МОЛ, (т.е. допустимы), 
что в большинстве случаев не соответствует бизнес-правилам предметной 
области, поскольку пропуски какой-либо нужной информации обычно 
недопустимы. Данное ограничение не именуется. 
РКІМАКҮ КЕҮ - ограничение первичного ключа, при этом автоматиче- 
ски накладывается ограничение МОТ МОЛІ. При задании значений пер- 
вичного ключа любое значение проверяется на уникальность и при обна- 
ружении дубликата операция прерывается. В таблице может быть только 
один столбец с ограничением РЕТМАКУ КЕҮ. 
ОМТОСЕ - ограничение уникальности (альтернативный ключ), ограниче- 
ние МОТ МОЛИ, также накладывается автоматически. Фактически, 
ОМЮЧЕ ничем не отличается от РВІМАВҮ КЕҮ, однако количество 
столбцов с ОМТОПЕ не ограничено. 
КЕЕЕКЕМСЕЅ имя главной таблицы — внешний ключ, который за- 
дается для столбца подчиненной (детальной) таблицы. Для значений 
внешнего ключа автоматически выполняется проверка на существование 
равного значения первичного ключа главной таблицы. При определении 
внешнего ключа могут быть дополнительно определены правила обеспе- 
чения ссылочной целостности. Например, правилами для удаления явля- 
ются: 

»®  ОМОЕГЕТЕ КЕЗТЕ!СТ - запретить удаление строки главной табли- 

цы, если в подчиненной есть хотя бы одна строка, которая на нее 
ссылается; 

• ОМ ОЕІЕТЕ САЅСАРЕ - вместе со строкой главной таблицы авто- 

матически удалить все ссылающиеся на нее строки подчиненной таб- 
лицы; 

е ОМРЕІЕТЕ ЅЕТ МО - при удалении строки главной таблицы ус- 
тановить во внешнем ключе ссылающихся строк значение МО. (это 
правило может быть определено только в том случае, если на внеш- 
ний ключ не наложено ограничение МОТ МОШ); 

е  ОМОЕГЕТЕ ЅЕТ РЕЕАТГТ – при удалении строки главной таблицы 
установить во внешнем ключе значение по умолчанию (это правило 
может быть определено только в том случае, если при определении 
внешнего ключа задано РЕЕАОГТ значение по умолчанию). 


По умолчанию принят запрет удаления строк при наличии ссылок на 
них (ОМ РЕГЕТЕ КЕЅТКІСТ). 

Аналогичные правила можно определить для обновления (ОМ ОР- 
"РАТЕ ...), однако необходимости в них обычно не возникает, т.к. пер- 
вичные ключи обновлять не принято. 
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СНЕСК - проверка логических выражений при изменении данных в 
столбце, например, СНЕСК (имя столбца ВЕТҰЕЕМ 1 АХО 100). 
Например: 
СВЕАТЕ ТАВГЕ 1 
(<1 МИМВЕК(8) РЕЕАОГТ 0 МОТ МОМ, СОМЅТКАІМТ ип ОМОЧЕ, 

с2 УАКСНАК(100) МОТ МО, 
) 

Создается таблица с именем +, содержащая два столбца: числовой 
столбец с1, обязательный для заполнения и принимающий значение 0 по 
умолчанию, все значения этого столбца уникальны (ограничение уни- 
кальности имеет имя ип) и текстовый столбец с2, обязательный для за- 
полнения текстом, его размер не более 100 символов. 


Ограничения таблицы 


Данные ограничения используются в том случае, если они затраги- 
вают сразу несколько столбцов: 

РКІМАКҮ КЕҮ (список столбцов) — составной первичный ключ; 
ОМТОТЕ (список столбцов) — составной альтернативный ключ; 
ЕОКЕІСМ КЕҮ имя внешнего ключа (список столбцов) КЕЕЕКЕМСЕЅ 
имя главной таблицы [правила поддержки ссылочной целостности]; 
СНЕСК (логическое выражение, затрагивающее сразу несколько столб- 
цов). 
Например: 
СВЕАТЕ ТАВГЕ 1 
(с1 МОМВЕКВ(3) МОТ МОЛИ, 

с2 РАТЕ МОТ МОЛИ, 

с3 МОМВЕК(3) МОТ МОЛИ, 

СОМ5ТВАПМТ рк 11 РЕТМАКУ КЕҮ(сІ,с2), 

СОМЗТВАПМТ ск 11 СНЕСК(с1+с3<=200) 
) 

Создается таблица с именем 11, содержащая три столбца, обязатель- 
ных для заполнения. Составной ключ таблицы включает столбцы с1 и с2 
(обратим внимание, что каждый из столбцов таблицы не обладает свойст- 
вами уникальности, поэтому РКІМАВҮ КЕУ не может быть ограничени- 
ем одного столбца). Ограничение СНЕСК также затрагивает сразу два 
столбца, поэтому оформлено как ограничение таблицы. 


84 


4.2.2. Удаление таблиц и изменение их структуры 


Команда удаления таблицы имеет вид: 
ОБОР имя таблицы 
Нельзя удалить таблицу, если существуют внешние ключи, ссылаю- 
щиеся на эту таблицу. Вместе с таблицей удаляются и созданные для нее 
индексы и триггеры. 
Команда изменения структуры таблицы выглядит так: 
АГТЕВ ТАВІЕ имя таблицы указания по изменению структуры 
Следует подчеркнуть, что команда АІ ТЕВ ТАВІЕ служит для изме- 
нения в определении таблицы и может быть применена только к сущест- 
вующим таблицам. В качестве указаний по изменению структуры табли- 
цы могут использоваться следующие фразы: 
АРр [СОГОММ] определение столбца – добавить столбец. 
Например: 
АГТЕК ТАВГЕ 1 Арр п МОМВЕК(4) МОТ МОМ, (— имя существующей 
таблицы, п — имя нового столбца ) 


Арр [СОМЅТКАІҸТ] ограничение — добавить ограничение. 
Например: 

АГТЕК ТАВГЕ 1 Арр РВІМАВҮ КЕҮ(п) 

ИЛИ 

АГТЕВ ТАВГЕ ї АРО СОМ5ТКАГУТ рк {РЕТМАБВУ КЕУ(п) 

В последнем примере ограничение первичного ключа получит имя рк { 


"КОР СОГОММ имя столбца 

"КОР [СОМТКАГУТ| ограничение 
Например: 

АГТЕК ТАВІЕ 1 ОВОР РВІМАВҮ КЕҮ(п) 
или 

АГТЕК ТАВІЕ { ВОР СОМ5ТКАП\Т рк 1 
АГТЕК ТАВІЕ 1 РВОР СОГОММ п 

АІТЕК (МОПІЕҮ в Огасе) но- 

вое определение существующего столбца 

При этом можно изменить тип, размер, ограничение МОГТИМОТ 
МОЦ, значение по умолчанию. Конечно, нельзя изменить имя столбца. 
Для этого следует удалить столбец со старым именем и добавить новый 
столбец с нужным именем. 

Следует отметить, что во многих случаях команда АІ ТЕК ТАВІЕ 
позволяет внести изменения в структуру таблицы, уже заполненной дан- 
ными (если они удовлетворяют вводимым ограничениям). В некоторых 
случаях требуется, чтобы столбец был пустым, например, сервер Огасе 
при удалении столбца требует выполнения этого условия. 
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Например: 

АІТЕК ТАВГЕ І 

МОРІГҮ с2 ҮАКСНАК (200) 

Увеличили предельный размер текста для столбца с2 


4.2.3. Пример создания базы данных 


Создадим демонстрационную базу данных из трех таблиц (Студен- 
ты, Предметы и Оценки), которая будет хранить сведения об успеваемо- 
сти студентов. Структура данной БД, конечно, сильно упрощена по срав- 
нению с тем, что требуется для решения реальной задачи учета успевае- 
мости студентов. Однако как пример для обучения основам ЗОГ, такая 
структура вполне подойдет. Назначение каждого столбца на изображен- 
ной ниже схеме, очевидно, понятно (рис. 4.1). 


Схема Базы Данных: 


ѕїџаепіѕ 
соа $1 ѕирјесїѕ 
йо соа и 
Бот 
рһопе 


Рис. 4.1. Схема демонстрационной базы данных 


Приведем различные варианты команд ОМІ для создания трех таб- 
лиц базы данных. 

Создание таблицы зе: 
СВЕАТЕ ТАВІЕ ѕіџйетіѕ 
( 
сой 51 МОМВЕВ (5) РВІМАВҮ КЕҮ, 
пате 5 УАВСНАК(100) МОТ МОГГ, 
Боги РАТЕ МОТ МІЛІ, 
рһопе СНАК (15) 
) 
Создание таблицы ѕибјесіѕ: 
СВЕАТЕ ТАВІЕ ѕибјесіѕ 


( 

сой ѕ0о МОМВЕК (4), 

пате 516 УАВСНАРВ (200) МОТ МОШ. 

) 

Изменение таблицы ѕибјесіѕ, добавление первичного ключа: 
АГТЕК ТАВІЕ ѕибјесіѕ 
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АБО РЕІМАВҮ КЕУ (соа ѕир) 

Изменение таблицы ѕибјесіѕ, добавление ограничения уникальности на- 
звания предмета: 

АГТЕВ ТАВІЕ ѕибјесіѕ 

АБО ОМОЧЕ (пате $16) 

Создание таблицы так: 

СКЕАТЕ ТАВІЕ тагкѕ 


( 

сой 51 МОМВЕВ(5) МОТ МО, ВЕЕЕВЕМСЕ$ ѕішйепіѕ 

ОМ РЕГЕТЕ САЅСАРЕ, 

сой 516 МОМВЕК(4) МОТ МОЛІ, КЕҒЕВЕМСЕЗЅ ѕџибјесіѕ , 

ша МОМВЕВ(1) СНЕСК (так ВЕТҰЕЕМ 2 АКШ 5), 

РВІМАВҮ КЕҮ(соа $, соа ѕир) 

) 

4.2.4. Создание таблиц на основе других таблиц 


Можно создать новую таблицу как результат запроса на выборку из 
одной или более существующих таблиц при помощи команды: 


СВЕАТЕ ТАВІЕ имя таблицы АЗ запрос на выборку 


Например, можно создать новую таблицу, являющуюся копией таб- 
лицы ѕірӣепіѕ: 
СКЕАТЕ ТАВІЕ сору ѕіоӣепіѕ АЗ 
ЗЕГЕСТ * ЕКОМ зе 

Новая таблица будет иметь такие же имена и типы столбцов, как и 
таблица 5а4ет$, содержать точную копию всех данных этой таблицы, но 
не будет иметь ее ограничений. 


4.3. Команды манипулирования данными 


Команды СВЕАТЕ ТАВІЕ ... и АІТЕВ ТАВГЕ ...никак не влияют 
на наполнение таблиц данными. Для этих целей используется язык ОМІ, 
(Ба Машрщайоп Гапоџаре), который позволяет полностью контролиро- 
вать процессы наполнения таблиц и измения данных. 

Основные команды манипулирования данными: 

ПУЗЕКТ – добавить данные 

РЕГЕТЕ - удалить данные изменяют состояние базы данных 
ОРРАТЕ - изменить данные 

ЗЕГЕСТ - выбрать данные без изменения состояния базы данных 
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Для фиксации изменений, произведенных командами ОРОАТЕ, ПЕ- 
ГЕТЕ, ІҸЅЕВТ, необходимо выполнить команду фиксации транзакции 
СОММІТ; можно отменить их действие командой КОГГВАСК (откат). 
Подробнее о транзакциях будет рассказано в следующем разделе. 

Следует отметить, что при выполнении команд ОРОАТЕ, ОЕГЕТЕ, 
ПУЗЕВТ СУБД автоматически проверяет все ограничения, которые были 
указаны при создании таблиц. Эти проверки, безусловно, существенно 
замедляют выполнение данных команд. Дополнительное время и другие 
ресурсы затрачиваются на обеспечение возможности отмены команды 
(отката). Однако все эти затраты окупаются гарантией того, что правила 
целостности данных, заложенные в команды ОПГ, ни при каких обстоя- 
тельствах не могут быть нарушены. 


4.3.1. Команда ІМЅЕВТ 


Вариант 1 - вставка одной строки 

Команда имеет вид: 

ТУЗЕВТ ТХТО имя таблицы [(список_имен столбцов)] 
УАГОЕ$ (список значений) 

Если в команде список имен столбцов опущен, то будут последова- 
тельно заполнены все столбцы в том порядке, в котором они были указа- 
ны в команде СВЕАТЕ ТАВГЕ. 

Например: 

ПУЗЕКТ ПУТО за ес5 УАГОЕ$ (5, Базы данных”) 
ПМЗЕКТ ІҸТО  54епб (сод 5 пате 56 Бош) УАГОЕЗ (3, 
‘Петров’,’12.03.1990) 

Во второй команде столбец рһопе (телефон) таблицы ѕіџйепіѕ можно 
оставить незаполненным, т.к. на него не наложено ограничение МОТ 
МОИ. 

Рассмотрим, при каких ситуациях данные команды могут привести к 
ошибке. В случае вставки нового предмета таких ситуаций две — уже есть 
предмет либо с кодом 5, либо с названием Базы данных (оба столбца 
предполагают проверку уникальности). Во втором случае на уникаль- 
ность будет проверен только один столбец сой $4. 

Команда 
ПУЗЕКТ ІМТО ѕибјесіѕ(соа 5, соа 56, тай) УАГОЕ® (3, 5, 1) 

в нашей демонстрационной базе данных не имеет никаких шансов вы- 
полниться, поскольку на столбец та наложено ограничение 
СНЕСК (так ВЕТҰЕЕМ 2 АХО 5) 
Исправим оценку: 
ПУЗЕВТ ПУТО ѕибјесіѕ(соа $, соа ѕиб, та К) УАГОЕЗ (3, 5, 4) 
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Мы уже знаем, что предмет с кодом 5 существует, как и студент с 
кодом 3, значит, ограничения внешнего ключа не нарушены. Однако мо- 
жет случиться последняя из возможных исключительных ситуаций — на- 
рушение уникальности составного первичного ключа таблицы тагК (сту- 
дент с кодом 3 уже имеет оценку по предмету с кодом 5). В случае, если 
уникальность не нарушена, новая строка благополучно добавится в таб- 
лицу тагкѕ. 

Вариант 2 – вставка множества строк на основе запроса по другим 
таблицам 

Команда имет вид: 

ПУЗЕВТ ТИТО имя таблицы [(список столбцов)] 

ЗЕГЕСТ ... (запрос на выборку из других таблиц) 
Например: 

ПУЗЕКТ ІМТО тагкѕ (соа $, сой ѕиб) 

ЗЕГЕСТ ѕіоаепіѕ.соа 5, ѕоирјесісоа ѕиб 

ЕКОМ зе, ѕоирјесі МНЕВЕ соа ѕир=5 

В данном примере в таблицу оценок будут добавлены все студенты, 
а в качестве предмета будет помещен предмет с кодом 5 (команда ЅЕ- 
ГЕСТ будет подробно рассмотрена в следующих лекциях). Теперь пре- 
подавателю этого предмета достаточно только проставить оценки в уже 
созданных строках. 

При выполнении команды ограничения проверяются для каждой 
вставляемой строки и в случае их нарушения хотя бы для одной из строк 
все данные не будут добавлены. Например, если кто-либо из студентов 
уже имеет оценку по предмету с кодом 5, автоматически выполнится ко- 
манда КОГТВАСК - откат. 

Команда не выполнилась бы и в том случае, если бы на столбец так 
было наложено ограничение МОТ МОМ. 


4.3.2. Команда ОЕТЕТЕ 


Общий вид команды: 
ОЕГЕТЕ ЕКОМ имя таблицы 
[\УУНЕКЕ условие отбора строк для удаления] 


Например: 

Удалить всех студентов с фамилией Иванов 
РЕГЕТЕ ЕВОМ ѕіџепіѕ 
\НЕВКЕ паше_5(=’Иванов” 

Более подробно фраза \УНЕВЕ будет рассмотрена в следуюшем раз- 
деле при изучении команды выборки. 

Полностью очистить таблицу ѕіџйепіѕ 
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РЕГЕТЕ ЕВОМ задет 

Нельзя удалить строку родительской таблицы, если есть связанные 
строки в подчиненной таблице и действует правило обеспечения ссылоч- 
ной целостности ОМ РЕГЕТЕ КЕЗТЕ!СТ. В приведенных выше примерах 
при определении внешнего ключа сой $ в таблице тагкѕ (оценки) было 
определено правило ОМ РЕГЕТЕ САЗСАПЕ, поэтому вместе со студен- 
тами будут каскадом удалены и все их оценки. Последняя команда, таким 
образом, очистит сразу две таблицы — $4еп и тагкѕ. 

Зато команда 
РЕГЕТЕ ЕКОМ ѕџбјесіѕ 
не удалит ничего, если в таблице тагкѕ имеется хотя бы одна строка, по- 
скольку при возникновении ошибки будут автоматически отклонены все 
изменения, сделанные этой командой. Если на момент выполнения этой 
команды таблица оценок была пуста, таблица предметов будет благопо- 
лучно очищена. 

Надо заметить, что для полной очистки таблицы существует более 
эффективная команда 
ТВОМСАТЕ ТАВІЕ имя таблицы 

Например: 
ТВОМСАТЕ ТАВІЕ тагкѕ 


4.3.3. Команда УРОАТЕ 


Данная команда не изменяет количество строк в таблице, поскольку 
ее назначение состоит в изменении данных, которые уже имеются в таб- 
лице. 

Общий вид команды: 

ОРБАТЕ имя таблицы ЅЕТ столбец1=значение [, столбец2=значение 
..] 
[УНЕКЕ условие отбора. строк] 

Например: 

Прибавим всем студентам по одному баллу к каждой оценке 
ОРБАТЕ тагкѕ ЗЕТ тагк= тагк+1 

При выполнении команды ОР”РАТЕ автоматически проверяются все 
ограничения столбца. В приведенном примере столбец та имеет огра- 
ничение СНЕСК, которое задает диапазон оценок от 2 до 5. Следователь- 
но, если в таблице имеется хотя бы одно значение оценки, равное 5, при 
увеличении на единицу оно выйдет за пределы диапазона, а все действия, 
выполненные командой, будут отменены. 

Чтобы гарантированно увеличить все оценки, кроме пятерок, изме- 
ним команду: 

ОРРАТЕ тагкѕ ЗЕТ так= так+1 
\НЕВЕ тагк<5 
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4.4. Команда выборки данных (ЗЕЁЕСТ) 


Команда выборки ЗЕГЕСТ является одной из самых мощных команд 
языка ОГ, которая реализует все операции реляционной алгебры и неко- 
торые предложения реляционного исчисления. Результатом команды вы- 
борки всегда является новая таблица (возможно, пустая или содержащая 
одно значение, которое трактуется как таблица из одной строки и одного 
столбца). 

Новая таблица является виртуальной, т.е. она существует (обычно в 
оперативной памяти) до тех пор, пока в ней есть необходимость, она мо- 
жет участвовать в другой команде ЗОГ, (СКЕАТЕ для различных объек- 
тов БД, ІЧЅЕВТ), в другой команде ЗЕГЕСТ (а также РЕГЕТЕ или ОР- 
РАТЕ) как результат вложенного запроса или передается клиенту для 
последующей обработки. 

Напомним, что при выполнении любой, сколь угодно сложной, ко- 
манды выборки состояние базы данных не изменяется, поскольку в про- 
цессе ее исполнения выполняются только операции чтения и обработки 
данных. 

Синтаксис команды, с учетом всех ее нюансов, является громоздким, 
поэтому приведем лишь общий порядок следования основных предложе- 
ний (фраз): 

ЅЕГЕСТ ЮІЅТІМСТ] список выражений(* - все столбцы таблицы) 
ЕВОМ список_таблиц, представлений, запросов 

(возможно, с операцией соединения ОТХ) 

[УНЕКЕ условия отбора строк] 

[СКОХЧР ВУ список выражений для группировки] 

[НАУІМХС условия отбора групп_с_ агрегатными функциями] 
[ОВОЕК ВУ список выражений для сортировки] 


Поскольку команда ЗЕГЕСТ является многофункциональной, разбе- 
рем по порядку возможности ее практического применения. 


4.4.1. Запросы на выборку по одной таблице 
Выборка всех данных таблицы 


ЗЕГЕСТ * ЕКОМ имя таблицы (представления) 

В дальнейшем при описании синтаксиса команд во фразе ЕКОМ бу- 
дем употреблять только имя таблицы, хотя везде вместо имени таблицы 
может быть имя представления. С представлениями мы познакомимся в 
следующем разделе, сейчас достаточно знать, что представление — это 
виртуальная таблица. 
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Например: выбрать все данные из таблицы 54 еп 
ЗЕГЕСТ * ЕКОМ адепт 

В такой форме запросы ставятся крайне редко, поскольку пересылку 
на компьютер клиента всех данных таблицы, хранимой на сервере, ра- 
зумно только для совсем небольших таблиц. В подавляющем большин- 
стве приложений требуется отобрать только часть столбцов и/или строк 
таблицы. Однако в процессе интерактивной работы, например, с утили- 
той ЗОГ, *РІ06 в Огае, символ * может оказать хорошую услугу, если 
имена столбцов неизвестны или хочется сократить время набора текста 
запроса. 

Отбор столбцов (операция проекции) 
ЗЕГЕСТ список имен столбцов ЕКОМ имя таблицы 

Например: 

выбрать столбцы с фамилией и датой рождения из таблицы студентов 

ЗЕГЕСТ пате $, богп ЕКОМ ѕіоаепіѕ 

выбрать только столбец с фамилией из таблицы студентов 

ЅЕГЕСТ пате $1 ЕКОМ вает 

Результаты выборки по этим запросам могут не удовлетворить поль- 
зователей по двум причинам. 

® Результаты не отсортированы и могут следовать в различном порядке 
в разные моменты времени (вспомним, что результат – таблица, ко- 
торая по определению представляет собой мультимножество строк, а 
в множестве или мультимножестве порядок следования элементов 
является несущественным). 

» В результатах могут содержаться строки-дубликаты (особенно во 
втором запросе при наличии однофамильцев), повторение одной и 
той же строки во многих случаях только затрудняет восприятие ре- 
зультата. 

Устранить перечисленные недостатки совсем несложно. 


Удаление строк-дубликатов из результатов запроса 


Для этих целей в команду выборки введено ключевое слово ОТЗ- 
ТІМСТ, которое записывается сразу после ЗЕГЕСТ. 

Например, для того, чтобы удалить дубликаты однофамильцев из 
предыдущего запроса, достаточно немного изменить его текст: 
ЅЕТЕСТ ОТЗТИМСТ пате $ ЕКОМ $4ещ 

При большом ожидаемом количестве строк-дубликатов в результа- 
тах запроса использование ОТЗТПУСТ позволяет существенно сократить 
размер выборки. 

Например, команда 
ЅЕГЕСТ ОТЗТИМСТ ша ЕКОМ тагкѕ 
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при существующей пятибальной системе возвратит максимум четыре 
строки, содержащих значения - 2,3,4,5. Порядок следования этих значе- 
ний предсказать невозможно, поэтому при необходимости получить ре- 
зультаты запроса в отсортированном виде необходимо явно указать в его 
тексте параметры, необходимые для сортировки. 


Сортировка результатов запроса 


Фраза ОВРЕК ВҮ..., необходимая для представления результатов 
выборки в отсортированном виде, обязательно должна быть последней в 
команде ЗЕГЕСТ, поскольку сортировка результатов всегда завершает 
выполнение запроса на выборку. 

После ключевых слов ОКРЕК ВУ следует указание, как именно тре- 
буется отсортировать результаты. Сортировка может быть выполнена по 
одному или нескольким столбцам. В последнем случае сначала выполня- 
ется сортировка по первому из столбцов, указанных в списке, в случае 
наличия одинаковых значений, строки с одинаковыми значениями сорти- 
руются по второму из столбцов и т.д. 

Сортировку можно выполнять по столбцам различных типов, ис- 
ключая типы больших объектов (ВГОВ, СГОВ). Сортировка по тексто- 
вым столбцам выполняется в лексикографическом (алфавитном) порядке, 
сортировка по столбцам даты и времени – в хронологическом порядке. 

По умолчанию значения сортируются по возрастанию (точнее, по 
неубыванию), но можно установить порядок сортировки «по убыванию» 
с помощью ключевого слова ОЕЅС[ЕМОІМС]. Можно и явно указать сор- 
тировку по возрастанию с помощью ключеого слова АЅС[ЕМРОІМ№О], но 
это никак не отразится на результате. Если сортировка выполняется сразу 
по нескольким столбцам, РрЕЅС необходимо указывать для каждого 
столбца в списке, для которого необходима сортировка по убыванию. 

Например, запрос 
ЗЕГЕСТ пате 5 ЕКОМ $в4еп5 ОКРЕК ВУ пате $ 
возвратит список студентов в алфавитном порядке, а запрос 
ЗЕГЕСТ паше_5{ ЕКОМ зв4ет5 ОКРЕК ВУ пате $, Боги 
не только отсортирует список в алфавитном порядке. но и расставит од- 
нофамильцев в соответствии с их возрастом (первым будет самый стар- 
ший, т.к. у него самая меньшая дата рождения). Если мы хотим расста- 
вить однофамильцев в порядке убывания даты рождения, следует изме- 
нить текст так: 

ЅЕГЕСТ пате $1 ЕКОМ ѕіџӣепіѕ ОКРЕК ВУ пате $, бош РЕЗС 

Если и сортировать фамилии требуется в порядке, обратном алфа- 
витному, текст будет выглядеть так: 

ЗЕГЕСТ пате 5 ЕКОМ ѕіоепіѕ ОКРЕК ВУ пате 5 ОЕЅС, бог РЕЗС 
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Из приведенных примеров видно, что сортировать результаты мож- 
но не только по столбцам, которые отбираются в запросе, но и по любым 
другим столбцам таблицы, на которой основан запрос. Если столбец сор- 
тировки уже указан в списке отбирающихся в запросе столбцов, во фразе 
ОВРЕВ ВУ можно указать его порядковый номер в списке. Например, 
запрос 
ЗЕГЕСТ пате $, богп ЕКОМ ѕірӣепіѕ ОКРЕК ВУ 1 
отсортирует результаты по первому столбцу в списке (это столбец 
пате $0. Такая дополнительная возможность позволяет немного сокра- 
тить текст запроса, но никак не влияет на его результаты. 

В списке ОВРЕВ ВУ в общем случае можно указывать произволь- 
ные выражения, в этом случае сортировка будет выполняться по значени- 
Ям данного выражения. 


Отбор строк (операция выборки) 


Все разобранные выше примеры возвращали данные для каждой 
строки таблицы $(а4еп (или тай$). Такие большие выборки обычно 
требуются только при формировании отчетов, большинство других задач 
требует предварительного отбора строк таблицы, необходимых пользова- 
телю. Напомним, что строки в таблицах не нумеруются, поэтому такие 
операции, как «извлечь первую строку таблицы», стандартом не поддер- 
живаются. 
В качестве критерия для отбора строк таблицы можно задать любое 
логическое выражение, используя фразу \/НЕКЕ. В процессе выполнения 
запроса быдет выполнен отбор только тех строк, для которых данное вы- 
ражение принимает значение «истина». Таким образом, результатом опе- 
рации выборки может быть произвольное число строк таблицы (от нуля 
до всех строк). 
Например, запрос: 
ЗЕГЕСТ * ЕВОМ задет У/НЕВЕ со4_$=10 
возвратит все данные о студенте, у которого личный код=10. Такой за- 
прос гарантированно вернет не более одной строки (если студента с ко- 
дом 10 в таблице нет, то запрос не вернет ни одной строки, но вернуть, 
например, двс строки он нс сможет, т.к. личный код студента обладаст 
свойством уникальности). 
Условие отбора строк может включать следующие операции: 
® операции сравнения <, >, <=, >=, !=(<>), = 
® операция проверки на отсутствие данных 1$ МОЛЛ. 
или их наличие 1$ МОТ МОИ, 

® логические операции: АХО, ОВ, МОТ 

® операция вхождения значения в заданный диапазон значений 
ВЕТУ/ЕЕМ начальное значение АМО конечное значение 
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® операция принадлежности значения заданному множеству 
ТМ (множество) 
® операция соответствия заданному шаблону (для текстовых столбцов) 

ПКЕ ‘шаблон’ 

В шаблоне для операции ГЛКЕ разрешено использовать два символа- 
заменителя: 

е  % заменяет последовательность из любого количества любых симво- 
лов (в том числе и пустая последовательность) 
® заменяет один любой символ в заданной позиции. 

Например. пусть требуется выбрать фамилии и телефоны всех сту- 
дентов, фамилия которых начинается на букву «С». Список отсортиро- 
вать по фамилии. Текст запроса: 

ЗЕГЕСТ паті $, рвопе 
ЕКОМ вает 

ҰНЕКЕ пате 5 ПКЕ `С%’ 
ОВПЕК ВУ 1 

Если в приведенном запросе заменить шаблон на ‘%С%”, то такой 
запрос выберет всех студентов, у которых в фамилии есть хотя бы одна 
буква «С». Если шаблон заменить на “С (после буквы С стоит пять 
знаков подчеркивания), то будут выбраны студенты, фамилия которых 
начинается на букву С и содержит 6 символов. 

При поиске по текстовым столбцам, в том числе по шаблону, обычно 
тонким моментом является чувствительность букв к регистру. Во многих 
СУБД заглавные и строчные буквы при поиске и сортировке не различа- 
ются, но, как правило, имеется возможность настройки чувствительности 
к регистру. В СУБД Огасе строчные и заглавные буквы в текстовых кон- 
стантах и шаблонах различаются, при сортировке также учитывается ре- 
гистр букв. 

Поэтому, например, при поиске студентов, в фамилии которых есть 
хотя бы одна буква С, в качестве условия отбора следует использовать 
\МНЕВКЕ пате $ ПКЕ ‘%С%’ ОВ пате $ ПКЕ ‘%с% 

Следует помнить, что запросы с операцией ПКЕ обычно выполня- 
ются довольно медленно, особенно если символ % стоит в начале шаб- 
лона (к такому запросу невозможно подключить древовидный индекс для 
ускорения поиска). Однако при поиске в текстовых столбцах данная опе- 
рация используется довольно часто. В Огасе версии 10 появилось и еще 
более мощное средство — поиск по регулярным выражениям, которое по- 
ка в стандарт языка ЗОГ, не вошло. 

Приведем еще ряд примеров запросов на выборку строк, демонстри- 
рующих применение различных операций. 
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Пусть требуется выбрать все строки из таблицы оценок, в которых 
присутствуют оценки 3 или 4. Запрос простой, но может быть выполнен 
несколькими разными способами: 

ЗЕГЕСТ * ЕКОМ тагкѕ \УНЕВЕ тагк=3 ОК тагк=4 
ЗЕГЕСТ * ЕКОМ тагкѕ ҮНЕКЕ тагк>2 АМ” тагк<5 
ЗЕГЕСТ * ЕВОМ тагкѕ МНЕВЕ так ІМ (3, 4) 

ЗЕГЕСТ * ЕКОМ тагкѕ МНЕКЕ так ВЕТУЕЕМ 3 АМР” 4 

Можно привести и еще несколько вариантов записи того же самого 
запроса, но и приведенных вполне достаточно, чтобы понять синтаксис 
различных операций. 

Требуется выбрать такие строки из таблицы студентов, в которых 
отсутствует телефон студента. 

ЗЕГЕСТ * ЕКОМ задет УНЕВЕ рһопе 1$ МОШ, 

Обратим внимание, что запрос 

ЗЕГЕСТ * ЕКОМ деп УНЕВЕ рһопе = МОШ, 

возвратит неправильный ответ, но при этом не будет получено сообщения 
об ошибке. 


Создание вычисляемых столбцов (операция расширения) 


Вычисляемый столбец – это фиктивный столбец, данные которого не 
хранятся в базе данных, а вычисляются на основе данных других столб- 
цов. Вычисляемому столбцу в запросе, как правило, присваивается какое- 
либо имя — псевдоним. В тексте запроса вычисляемый столбец выглядит 
так: 

ЗЕГЕСТ ... выражение для вычисления [А5] псевдоним ... 

Вообще, псевдоним можно присвоить и любому столбцу, указанно- 
му в списке для отбора, но для вычисляемых столбцов это особенно акту- 
ально, поскольку в случае отсутствия псевдонима СУБД формирует имя 
вычисляемого столбца автоматически, обычно такие имена бывают длин- 
НЫМИ И неудобочитаемыми. 

Например, пусть требуется выводить возраст студента вместо его 
даты рождения. Для этого необходимо создать вычисляемый столбец на 
основе выражения, которое вычисляет возраст, используя дату рождения 
и текущую дату. Приводимый запрос будет работать только в СУБД 
ОгасІе, поскольку использует ее функцию ѕуѕӣаѓе для получения текущей 
даты. Разность двух дат исчисляется в днях, которые затем переводятся в 
возраст в годах: 

ЗЕГЕСТ со4 5, пате_$4, їгипс((ѕуѕаӢаіе-рогп)/365.25) аве ЕВОМ зе 

В выражениях для вычисляемых столбцов могут использоваться: 
® имена столбцов 
• константы 
• операции 
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® функции 
® круглые скобки. 

Числовые и текстовые константы записываются обычным способом, 

например, запрос: 

ЅЕГЕСТ ‘студент’ ЕКОМ зе 

столько раз выведет слово студент, сколько строк имеется в таблице $- 
аепіѕ (разумеется, данный запрос не имеет никакого практического смыс- 
ла). Можно заметить, кстати, что в Огае фраза ЕКОМ в запросах являет- 
ся обязательной, поэтому в любой базе данных автоматически создается 
таблица с именем 4иа|, состоящая из одной строки и одного столбца, ко- 
торая может использоваться в запросах, выводящих константы или сис- 
темные функции. Например, запрос: 

ЗЕГЕСТ и5ег ЕКОМ ара! 

возвратит имя пользователя, который открыл тот сеанс связи с сервером, 
в котором выполняется данный запрос. 

Набор арифметических операций является стандартным (в стандарте 
имеется еще операция возведения в степень **, которая в большинстве 
СУБД не реализована). Для текстовых данных часто используется опера- 
ция конкатенации, которая в стандарте и большинстве СУБД обозначает- 
ся двумя вертикальными линиями (||) вместо привычного знака «+», кото- 
рый также используется в некоторых СУБД (Ассеѕѕ, Місгоѕой ЗОГ, 
Зегует). 

Например, выведем фамилию и телефон студентов в виде одного 
текстового столбца для тех студентов, телефон которых известен: 
ЗЕГЕСТ пате $ ||’ тел. ‘|| рһопе АЅ пате рћопе ЕКОМ $а4еп$ 
\НЕКЕ рһопе [$ МОТ МОЛИ. 

В выражениях для вычисляемых столбцов могут использоваться 
также скалярные функции. Стандарт ЗОГ, 2003 содержит довольно боль- 
шой набор функций, которые делятся на скалярные и агрегатные. Агре- 
гатные функции будут подробно рассмотрены далее. Сейчас кратко кос- 
немся скалярных функций. Основная проблема их использования в ЗОГ.- 
запросах состоит в том, что, к сожалению, различные СУБД поддержи- 
вают различный набор функций, который часто не совпадает со стандарт- 
ным набором, определенным в 501 2003. Поэтому запросы, в которых 
содержится обращение к функциям, при переносе их на другую СУБД, 
скорее всего, потребуют изменения текста, что несколько ограничивает 
применение функций. 

Все скалярные функции можно разбить на следующие группы (в 
скобках приводятся примеры функций, которые поддерживаются в 
Отасе): 

• текстовые функции; используются для управления текстовыми стро- 
ками, например, для удаления ведущих и завершающих пробелов 
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(функции ГТЕТМ ВТКІМ), получения фрагмента строки (функция 
ЗОВЗТК) или преобразования букв в верхний или нижний регистр 
(функции ОРРЕК и _ОМЕВ) 

• числовые функции; используются для выполнения математических 
операций над числовыми данными, например, для вычисления абсо- 
лютных значений (функция АВ5) и выполнения алгебраических вы- 
числений (тригонометрические функции, логарифмы, остаток от де- 
ления – функция МОР, округление и усечение — функции КООМР и 
ТЕОМО) 

• функции даты и времени; используются для управления значениями 
даты и времени и для выборки отдельных частей этих значений, на- 
пример, для возвращения года, месяца, дня или дня недели для за- 
данной даты 

® функции преобразования типов данных, например, преобразовать 
дату или число в строку текста и наоборот (в стандарте СНАК(Х), 
РАТЕ(х) и т.д., в Огасіе аналогичные функции ТО СНАРВ (х, стро- 
ка формата), ТО РАТЕ(х, строка формата) ит.д.) 

® системные функции, например, уже упоминавшиеся имя пользовате- 
ля (функция ОЗЕК) или системная дата (функция ЗУЗОАТЕ). 


Использование оператора САЗЕ в вычисляемых столбцах 


Данный оператор позволяет организовывать ветвления в вычисляе- 
мых столбцах, что позволяет внести в запрос элементы процедурной ло- 
гики. Он аналогичен, например, оператору саѕе из языка Разса| или опе- 
ратору ѕуіїсһ из языка С. Например, запрос: 


ЗЕГЕСТ со4_$, сой ѕир, САЗЕ тагк 

\НЕМ 5 ТНЕМ ‘ОТЛИЧНО’ 

\НЕМ 4 ТНЕМ ‘ХОРОШО? 

\УНЕМ 3 ТНЕМ `УДОВЛЕТВОРИТЕЛЬНО” 

У\У/НЕМ 2 ТНЕМ ‘ПЛОХО? 

ЕМО так ЕКОМ тагкѕ 

вместо цифры выведет оценку в виде соответствующего слова. 


Использование агрегатных функций 


Важной функцией любой информационной системы является авто- 
матическое формирование отчетности на основе данных, хранящихся в 
БД. Во многих отчетах требуется отображать не сами данные (их слиш- 
ком много), а результаты их статистической обработки, например, сум- 
марные или средние значения по различным показателям. Выполнять ста- 
тистическую обработку данных в клиентских приложениях неэффектив- 
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но, поскольку при этом придется пересылать по сети большое количество 
необработанной информации с сервера. Более разумным решением явля- 
ется обеспечение возможности выполнять статистическую обработку 
данных непосредственно на сервере. 

С этой целью в команду ЗЕГЕСТ введены агрегатные (статистиче- 
ские, итоговые) функции. Основная особенность этих функций состоит в 
том, что каждая из них вычисляет одно итоговое значение по какому- 
либо столбцу (это может быть и вычисляемый столбец) для множества 
строк таблицы. 

В стандарте определено 5 агрегатных функций: 

Ѕ50М(имя столбца) — сумма значений заданного столбца, 

АУС(имя столбца) – среднее значение 

МІМимя столбца), МАХ(имя столбца)- минимальное и максимальное 
значение 

СОСМТ([рІЅТІМСТ] * или имя столбца) – подсчет количества строк. 

Первые две функции (сумма и среднее) могут быть вычислены толь- 
ко по числовым столбцам, максимальное и минимальное значения могут 
быть определены для столбцов всех типов (кроме больших объектов), при 
этом строки текста сравниваются в лексикографическом, а даты – в хро- 
нологическом порядке. 

Например: 

Подсчитать средний балл по всем студентам и предметам 
ЗЕГЕСТ АУС (ша) аур так ЕВОМ тагкѕ 

Найти минимальную и максимальную даты рождения студентов 
ЗЕГЕСТ МІМ(Богп) тіп даѓе, МАХ(Богп) тах_4ае ЕКОМ $@4ет 

Функция СООМТ, казалось бы, вообще не должна содержать аргу- 
ментов, поскольку ее назначение — подсчет количества строк, что она и 
делает, если в качестве аргумента используется символ-заменитель *. Од- 
нако, если в качестве аргумента использовать имя столбца, данная функ- 
ция будет подсчитывать количество непустых значений в данном столб- 
це. Второй вариант аргумента разумно использовать, только если столбец 
не имеет ограничения МОТ МОШ. Использование ключевого слова р18- 
ТІҸСТ приводит к тому, что подсчитывается количество уникальных 
значений в заданном столбце. 

Например: 

Посчитать количество студентов (количество строк в таблице вает) 
ЅЕТЕСТ СООМТ (*) соџпі ѕёойепіѕ ЕКОМ $а4ет 

Подсчитать количество студентов, для которых известен номер их 
телефона. 

ЅЕГЕСТ СООМТ (рһопе) сои рћһопеѕ ЕКОМ ше 

Подсчитать количество уникальных значений оценок в таблице так: 

ЗЕГЕСТ СООМТ (РУЗТИХСТ тагк) сои _так$ ЕВОМ тагкѕ 
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Отметим, что запросы, вычисляющие агрегатные функции по всей табли- 
це, всегда возвращают одну строку, содержащую итоговые данные. Поэтому в 
списке выражений, следующим за словом ЗЕГЕСТ, могут быть только агре- 
гатные функции (или выражения на основе агрегатных функций). 


Группировка и агрегатные функции 


Агрегатные функции могут вычисляться как по всей таблице, так и 
по отдельным группам строк, в последнем случае над таблицей ВЫПОЛНЯ- 
ется операция группировки. 

При группировке формируются группы с одинаковыми значениями в 
столбце группировки (или нескольких столбцах), запрос возвращает 
столько строк, сколько получилось групп. Фактически количество групп 
совпадает с количеством уникальных значений в столбце группировки, 
поэтому группировку принято выполнять по столбцам, содержащим 
большое количество повторяющихся значений. Тогда количество групп 
будет значительно меньше, чем количество строк в таблице. 

В базе данных, которую мы используем для демонстрационных при- 
меров, наиболее подходящей для группировки является таблица оценок 
тагкѕ, в которой каждый столбец содержит большое количество повто- 
ряющихся значений и может быть использован в качестве столбца груп- 
пировки. 

Например, сгруппировав эту таблицу по столбцу сой $, можно под- 
считать различные итоговые данные по каждому студенту. Так, запрос: 
ЗЕГЕСТ соа $, ау (тай) аус так, сои так) соџпі тагк 
ЕКОМ тагкѕ 
ОКОТР ВУ сой і 
возвращает средний балл и количество оценок для каждого студента. 
Вместе с итоговыми данными запрос возвращает коды студентов, для 
которых подсчитаны итоговые данные. Вывод столбца сой $ в приведен- 
ном запросе может быть выполнен корректно, поскольку при выполнении 
группировки в каждой группе оказались одинаковые коды студентов (но 
разные предметы и разные оценки). 

Если выполнить группировку таблицы тагкѕ по столбцу сой 56 
(код предмета), то можно подсчитать те же итоговые данные по каждому 
предмету. Но тогда в список вывода запроса, кроме агрегатных функций, 
можно включить только код предмета. 

ЗЕГЕСТ соа ѕир, аур(тагк) аус тагк, сои (тай) сооп таг 
ЕКОМ тагкѕ 
СКОТР ВУ соа ѕир 
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Обобщив примеры, выведем общее правило для запросов с группи- 
ровкой: 
в списке выражений, который следует за словом ЗЕГЕСТ, могут быть 
только выражения из фразы СКООР ВУ и агрегатные функции (или вы- 
ражения на их основе). 


Условия отбора групп 


После группировки можно отобрать группы, удовлетворяющие оп- 
ределенному условию. Для этих целей служит фраза НАУІМОС.. 
Например, пусть требуется выбрать тех студентов, у которых сред- 
ний бал >4. Текст запроса имеет вид: 
ЗЕГЕСТ соа 5, АУС(тагк) аув тагк 
ЕКОМ тагкѕ 
ОКОТР ВУ сой $ 
НАУПМО АУб(тагк)>4 
Следует отметить, что фраза НАУІМС может использоваться только 
после фразы СКОТР ВУ. 


4.4.2. Соединение таблиц в запросах 


Запросы по одной таблице составляют малую долю всех запросов к 
базе данных. Например, запросы с группировкой, которыми завершалась 
предыдущая лекция, при использовании только одной таблицы оценок 
тагкѕ выдают числовые коды студентов или предметов, тогда как при 
формировании отчетов требуются фамилии студентов и названия предме- 
тов. Но эти данные хранятся в других таблицах (ѕ(џйепіѕ и ѕибјесіѕ). 

Подобная ситуация является типичной для любой нормализованной 
базы данных, состоящей из большого числа таблиц. В связи с этим, одна 
из самых распространенных операций в запросах на выборку – операция 
соединения таблиц. Соединять таблицы в запросах можно различными 
способами, при этом могут получаться различные результаты, поэтому 
данная операция требует повышенного внимания. 


Способы соединения таблиц в запросе ЅЕЕСТ 


1. Декартово произведение 

Это операция, при выполнении которой каждая строка одной табли- 
цы соединяется (склеивается) с каждой строкой другой таблицы. Декар- 
тово произведение таблиц выполняется в том случае, если во фразе 
ЕКОМ присутствует список из нескольких таблиц, но не задается ни опе- 
рация соединения ЈОЇҸ, ни условие для соединения таблиц во фразе 
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ҰУНЕВЕ. Обычно таблицы, которые соединяются посредством декартова 
произведения, не имеют общих столбцов. 

Так, запрос вида: 

ЗЕГЕСТ ... ЕВОМ таблица1, таблица? 

возвратит количество строк, равное произведению количества строк пер- 
вой таблицы на количество строк второй таблицы, поскольку склеит каж- 
дую строку таблицы! с каждой строкой таблицы?. Если не выполнять 
операцию отбора столбцов, в результат войдут все столбцы таблицы] и 
таблицы2, т.е. количество столбцов равно сумме количеств столбцов таб- 
лицы1 и таблицы2. В общем, размеры таблицы-результата оказываются 
весьма внушительными. 

На практике декартово произведение таблиц используется крайне 
редко. Например, для нашей демонстрационной базы данных выполнять 
соединение всех студентов со всеми предметами (т.е. выполнять декарто- 
во произведение таблиц $а4ещб и ѕибјесіѕ) разумно только в том случае, 
если все учатся по единому плану и сдают экзамены по всем предметам, 
занесенным в таблицу ѕибјесіѕ. Соединять всех студентов или все предме- 
ты со всеми оценками — вообще полная бессмыслица. 

Иногда в базе данных встречаются таблицы, которые содержат всего 
одну строку для хранения каких-либо констант (название вуза, мини- 
мальный размер оплаты труда и т.д.). Такие таблицы можно подключать к 
любому запросу, используя операцию декартова произведения. 

На практике декартовы произведения иногда возникают из-за ошиб- 
ки в записи текста запроса. Основным способом соединения таблиц явля- 
ется операция внутреннего или естественного соединения. 

2. Внутреннее (естественное) соединение таблиц 

Таким способом можно соединять только таблицы, имеющие общие 
столбцы. При выполнении данной операции соединяются (склеиваются) 
только строки, имеющие общие значения в столбце связи. Как правило, 
таким способом соединяются таблицы, связанные отношением «один-ко- 
многим», а в качестве столбцов связи используются первичный КЛЮЧ 
главной таблицы и внешний ключ подчиненной. Таким образом, те стро- 
ки главной таблицы, для которых нет связанных строк в подчиненной 
таблице, при внутреннем соединении вообще не попадут в результат за- 
проса. 

В языке ЗОГ, имеются 2 способа реализации внутреннего соединения 
таблиц, оба этих способа являются равноценными и обычно приводят к 
одному и тому же плану исполнения запроса. Однако с точки зрения ре- 
ляционной алгебры они используют различные операции, и тексты запро- 
сов несколько отличаются друг от друга: 
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а) выборка из декартового произведения 
Начнем с примеров. Пусть требуется вывести фамилии всех студен- 
тов и их оценки. Текст запроса будет выглядеть так: 


ЗЕГЕСТ зв4еп($.пате_$, тагкѕ. тагк 
ЕВОМ 5ва4еп(з, тагкѕ 
\НЕВЕ ѕіџаепіѕ.соа ѕ=тагкѕ.сой $ї 
б) операция соединения [ПММЕВ] ЈОІҸ 
Тот же самый запрос, соединяющий студентов с их оценками, будет 
записан несколько по-другому: 


ЅЕТЕСТ ѕёоаепіѕ пате $, тагкѕ.тагк 
ЕКОМ вет ЈОГЧ тагкѕ 
ОМ ѕіоаепіѕ.соа ѕ=тагкѕ.соа $1 


Результаты запросов (а, б) будут абсолютно аналогичны и могут вы- 
глядеть примерно так: 


пате $ так 
Иванов 5 
Иванов 3 
Петров 4 
Петров 5 
Петров... 5 


Каждая фамилия студента повторяется в результирующей таблице 
столько раз, сколько оценок получил данный студент. Если в таблице 
уе есть, например, строка с фамилией Сидоров, который пока еще не 
получил ни одной оценки, в результирующей таблице этой фамилии во- 
обще не будет. Так работает операция внутреннего соединения. 

Обратим внимание на некоторые особенности приведенных выше 
примеров. 

Во-первых, в тексте запросов используются составные имена столб- 
цов, записанные с использованием точечной нотации: 

имя таблицы.имя столбца 

Использование составных имен позволяет избежать неоднозначно- 
сти в записи имени столбца, поскольку разные таблицы могут содержать 
одноименные столбцы. В принципе, если имя какого-либо столбца уни- 
кально в пределах тех таблиц, которые указаны во фразе ЕКОМ, можно 
ограничиться и простым именем, но использование составных имен везде 
является более грамотным. Такие запросы и компилируются быстрее. 

Во-вторых, в обоих приведенных выше запросах явно задано усло- 
вие соединения в виде равенства столбцов связи  (5- 
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4еп65.со4_5(=тагК$.соЯ_50. Казалось бы, можно сократить текст запроса, 
ведь в таблицах $а4еп5 и тагкѕ только один общий столбец со4_$. Од- 
нако соединение двух таблиц вовсе не обязательно должно выполняться 
только по первичному и внешнему ключу. Любые два столбца, совпа- 
дающие по типу, могут быть использованы в условии соединения таблиц. 
Разумеется, связывать строки, используя неключевые столбцы ДЛЯ СВЯЗИ, 
нужно с предельной осторожностью. Допустим, запрос, в котором уста- 
навливается связь с помощью условия ѕіоӣепіѕ.сой ѕі=тагкѕ.сой 516, бу- 
дет синтаксически правильным (он даже исполнится и возвратит резуль- 
таты), но абсолютно бессмысленным. Будьте предельно внимательны при 
записи условий соединения! 


Использование псевдонимов таблиц в запросах с соединением 

Можно несколько сократить тексты приведенных выше запросов за 
счет использования коротких псевдонимов вместо довольно длинных 
имен таблиц. 

Например, текст запроса, соединяющего студентов с оценками, мо- 
жет выглядеть так: 

ЗЕГЕСТ $.пате_ $, т.таЖ 
ЕКОМ ѕшаепіѕ $1, тагкѕ т 
\НЕВЕ ѕі сой ѕі=т.сой 51 

или так: 

ЅЕГЕСТ $ пате $, т.тагк 
ЕКОМ ѕірепіѕ 5 ЈОТҸ тагкѕ т 
ОМ ѕісоа ѕЅі=т.сой $1 

В дальнейших примерах мы будем использовать псевдонимы таб- 
лиц. 

Приведенные запросы не возвращают важной информации, по каким 
именно предметам студент Иванов или Петров получил те или иные 
оценки. Для того, чтобы в результатах запроса появилось название пред- 
мета, необходимо в тексте запроса добавить соединение еще с одной 
таблицей ѕџбјесіѕ: 

а) вариант с выборкой из декартова произведения: 

ЅЕТЕСТ ѕі.соа $, $. пате $, $. пате 56, т.тагк 
ЕКОМ ѕаепѕ $1, тагкѕ т, ѕибјесіѕ $ 
ҰМНЕВЕ ѕі сой ѕі=т.сой $1 АМР” $.сой ѕир=т.сой ѕиб 


0) вариант с использованием операции соединения: 
ЅЕТЕСТ ѕі.соа $, $. пате $, $. пате 56, т.тагк 
ЕКОМ з4еп($ 5 ЈОТЧ тагкѕ т ОМ $(.сой ѕі=т.сой 51 
ЈОТМ ѕибјесіѕ $ ОМ ѕ.соа ѕир=т.сой ѕиб 
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Результаты этих запросов опять одинаковы и предоставляют исчер- 
пывающую информацию об успеваемости студентов в виде одной боль- 
шой ненормализованной таблицы: 


соа $1 пате $ пате ѕиб так 
1 Иванов Математика 5 
1 Иванов Физика 4 
2 Петров Физика 4 
2 Петров Информатика 5 
2 Петров История 4 
3 Иванов Математика 4 
3 Иванов Информатика 3 


Как можно понять из текста запросов, приведенных выше, для каж- 
дой добавляемой в запрос новой таблицы необходимо добавить условие 
ее соединения с другой таблицей, в противном случае будет выполнена 
операция декартова произведения. В общем случае, если в запросе ис- 
пользуется п таблиц, нужно записать п-1 условий их соединения. 

Следующий пример запроса выводит ФИО, код студента и средний 
балл (обратим внимание на то, что группировку придется выполнять сра- 
зу по двум столбцам, чтобы выполнилось правило для запросов с группи- 
ровкой, которое было рассмотрено в предыдущей лекции). 


ЗЕГЕСТ $.с04_$, $ пате 5, АУС(т.тагк) аур тагк 
ЕКОМ $а4еп $, тагкѕ т \/НЕВЕ $.соа ѕі=тп.соа 51 
СООР ВУ ѕ.соа $, $ пате $! 
Есть и еще один вариант обхода правила для запросов с группировкой: 
ЗЕГЕСТ $.соа 51, МАХ (ѕі пате $) пате 5, АУС(т. та) аур тагк 
ЕКОМ ѕіпаепёѕ $, тагкѕ т \/НЕВЕ ѕісоа ѕ=т.соа ѕї 
ОВОТР ВУ ѕі.соа ѕї 

В приведенном примере использование агрегатной функции 
МАХ($.паше_50 выглядит искусственным, с таким же успехом можно 
использовать и функцию МІМ, однако любая из этих функций позволит 
выполнить группировку только по одному столбцу сой $. 

3. Внешнее соединение таблиц (операция ОСТЕК ЈО) 

При внешнем соединении, в отличие от внутреннего, в результат 
выборки попадают не только все связанные строки обеих таблиц, но и 
строки одной из таблиц (или обеих), для которых нет связанных в другой 
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таблице. Недостающим значениям столбцов другой таблицы при этом 
присваивается значение МОТ... 

Возможны три варианта внешнего соединения двух таблиц (выборка 
дополняется строками таблицы, стоящей слева от слова ЈОІМ, или табли- 
цы, стоящей справа, или обеих сразу), поэтому различают три вида внеш- 
них соединений: 

ГЕЕТ [ООТЕВ] ОГМ - левое внешнее соединение 
ВІСНТ [ОТЕК] ЈОІМ - правое внешнее соединение 
РОГ, [ООТЕВ] ЈОІМ – полное внешнее соединение. 

Например, перепишем предыдущий запрос (код, фамилия и средний 
балл студента), используя внешнее соединение таким образом, чтобы 
студенты, у которых вообще нет оценок, попали бы в список вывода с 
МОЛЛ -значениями среднего балла. 

ЗЕГЕСТ ѕі.соа $, $1. пате $, АУС (т. так) аур так 
ЕКОМ з4еп$ 5 СЕЕТ ЈОІМ тагкѕ т ОМ $.соа ѕі=т.сой 51 
СКОТР ВУ $.со4_5%, $. пате 51 

Мы уже знаем, что внутреннее соединение таблиц часто оформляет- 
ся в тексте запроса, как выборка из декартова произведения. Можно ли 
использовать этот способ для внешнего соединения? 

В некоторых СУБД можно, но, как и все нестандартные конструк- 
ции, это плохо влияет на переносимость запроса. Все же приведем вари- 
ант записи внешнего соединения таблиц, используя синтаксис СУБД 
ОгасІе (на примере того же самого запроса - код, фамилия и средний балл 
студента). 

ЗЕГЕСТ ѕ.соа $, ѕі пате 5, АУС (т/тагк) аур тагк 
ЕВОМ ѕіџӣепіѕ $6 тагкѕ т 

ҰУНЕВЕ ѕ(.соа ѕ=т.соа $ (+) 

СООР ВУ ѕ(.соа $, 5. пате $! 

Используемая здесь синтаксическая конструкция (+) добавляет фик- 
тивные строки в таблицу тагкѕ для тех студентов, у которых нет оценок, 
при этом в столбец так помещается значение МОШ. 

Рассмотрим некоторые особенности использования функции 
СООМТ в запросах с внешим соединением таблиц. Пусть требуется вы- 
вести количество оценок для каждого студента из таблицы ѕіџйепіѕ. Если 
студент еще не имеет ни одной оценки, должно быть выведено количест- 
во 0. Текст запроса, использующий операцию ГЕЕТ ЈОІХ: 

ЗЕГЕСТ $.с04_5%, $.пате_5, СООМТ(т.тагк) сои тай 
ЕКОМ зе $ ГЕЕТ ЈОІМ тагкѕ т ОМ $.соа ѕі=1п.сой $ 
СВООР ВУ ѕі.соа $, $1. пате 

Использование конструкции СООМТ(т.тагк) позволит получить 
правильные результаты и вывести значение 0 для студентов, не имеющих 
оценок. Однако, если использовать в этом же запросе СООМТ(%), то для 
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студентов, не имеющих оценок, будет выведено количество 1 (!) и их 
нельзя будет отличить от студентов, которые имеют одну оценку. 

Такие результаты вполне согласуются с правилами стандарта ЗОГ, 
поскольку операция внешнего соединения добавляет в таблицу тагкѕ 
фиктивную строку, а функция СОЧМТ(*) ее добросовестно подсчитывает. 
Функция СООМТ(т.тагк) учитывает, что в фиктивных строках, а также в 
реальных строках, где преподаватель не выставил оценку, значение 
столбца т. так равно МОШ. 

Совсем интересные результаты получатся при использовании конст- 
рукции СООМТ(ОТСТПУСТ т.тагК). В этом случае будет подсчитано ко- 
личество различных оценок каждого студента (например, для круглых 
отличников это значение равно 1 — одни пятерки) 

4. Самосоединения 

Это соединение таблицы со своей копией. Подобные соединения ис- 
пользуются сравнительно редко, но при решении некоторых задач могут 
оказаться полезными. 

Например, пусть требуется вывести всех однофамильцев, т.е. фами- 
лии, которые встречаются в таблице студентов более одного раза: 
ЗЕГЕСТ ОТЗТИХСТ $1.пате_5 ЕКОМ зе $1, эбен 52 
\НЕВЕ $1.паше_5=52.пате_5 АМО” $1.с04_5<>52.с04_$ 

Ключевое слово ОТЗТПМСТ здесь добавлено на тот случай, если в 
таблице встречаются фамилии, повторяющиеся более двух раз (такие фа- 
милии несколько раз попадут в результат запроса). 

Следует отметить, что ту же задачу можно решить более эффектив- 
но, используя запрос: 

ЗЕГЕСТ паше_5 ЕКОМ ѕоаепіѕ 
СВООР ВУ паше_$ 
НАУПМО СООМТ(пате $0 > 1 

Так что будем считать первый из приведенных вариантов лишь ил- 
люстрацией к операции самосоединения таблиц в запросах на выборку. В 
связи с этим стоит отметить, что часто вопрос об эффективности того или 
иного запроса для конкретной СУБД приходится решать эксперимен- 
тально, поэтому при решении задачи желательно рассмотреть несколько 
вариантов текста 501 -запроса с целью выбора наиболее эффективного. 


4.4.3. Вложенные запросы 


Это запросы, которые содержатся в теле другого запроса. Они могут 
использоваться во фразах ЕКОМ, МНЕВЕ и НАУІМ“С, а также в списке 
после слова ЗЕГЕСТ, создавая, таким образом, вычисляемый столбец. 

Вложенные запросы – прекрасное средство разработки сложных за- 
просов выборки данных, которые позволяют применить алгоритмический 
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подход к решению задачи, представив сложную задачу выборки в виде 
последовательности более простых задач, каждую из которых можно 
оформить в виде вложенного запроса. 
Перечислим несколько основных правил, которые должны соблю- 
даться при использовании в запросе вложенных запросов: 
® тело вложенного запроса всегда заключается в скобки 
® вложенные запросы могут содержать другие вложенные запросы, при 
этом выполнение запроса всегда начинается с самого «глубокого» 
вложенного запроса и заканчивается внешним запросом 
• во вложенном запросе не следует использовать фразу ОКРЕКВ ВУ, 
поскольку сортировка результатов должна быть выполнена один раз 
после выполнения всего запроса целиком 
Другие особенности использования вложенных запросов рассмотрим 
немного позже. Перейдем к примерам. 


Вложенные запросы во фразе ЕКОМ 

Это одна из самых простых и понятных ситуаций использования 
вложенных запросов. Поскольку любой запрос возвращает результаты в 
виде таблицы, то использование конструкции 
ЗЕГЕСТ .... ЕКОМ (ЗЕГЕСТ ... ) 
полностью равнозначно 
ЗЕГЕСТ .... ЕКОМ имя_таблицы 

Например, пусть требуется найти значения минимального и макси- 
мального среднего балла студентов. Для решения этой задачи сначала 
необходимо подсчитать средние баллы по каждому студенту, что можно с 
успехом выполнить во вложенном запросе. Результаты вложенного за- 
проса затем используются во внешнем запросе как обычная таблица из 
одного столбца аур тагк (задание псевдонима во вложенном запросе 
обязательно), над которой производится вычисление агрегатных функций 
МІМ и МАХ. 
ЗЕГЕСТ МІМ (аур тагк) тіп ауе так, МАХ(аур тагк) тах аур таг 
ЕКОМ (ЗЕГЕСТ АУС (тагк) аус тагк ЕКОМ тагкѕ СКООР ВУ соа $0 

Если во вложенном запросе выполнить группировку таблицы оценок 
по предмету (сой $16), будут получены минимальный и максимальный 
средний балл по предметам. 


Вложенные запросы как альтернатива соединению таблиц в запросах 
Этот вариант использования вложенного запроса во многих (но не во 
всех!) случаях позволяет избежать операции соединения таблиц. Текст 
такого запроса выглядит понятно и логично, эффективность для многих 
СУБД сравнима с использованием операции соединения, но существен- 
ного ускорения запроса таким способом не добиться. Тем не менее, как 
альтернативный вариант соединению, он заслуживаеи внимания. 
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Например, пусть требуется выяснить оценку студента Иванова по 
математике (если таких студентов несколько — все оценки). Можно легко 
решить эту задачу, соединив таблицы $4еп$, 516]ес5 и тагкѕ и выпол- 
нив выборку из полученной в результате соединения таблицы. Однако, 
логичным представляется и такой вариант: найти коды всех Ивановых из 
таблицы $(а4еп(5, найти код математики из таблицы ѕибјесіѕ, на послед- 
нем этапе найти оценку (или несколько оценок) в таблице таз. Получа- 
ем такой текст запроса с двумя вложенными запросами: 

ЗЕГЕСТ так ЕКОМ тагкѕ 

\НЕКЕ соа $ ПУ 

(ЗЕГЕСТ соа 5 ЕКОМ а4ещб МНЕВЕ пате_5=’Иванов”) 

АМР сой 516 ІЧ 

(ЗЕГЕСТ соа ѕир ЕКОМ ѕибјесіѕ УНЕВЕ пате ѕ$06='Математика”) 

Обратим внимание на использование операции ПМ (принадлежность 
значения множеству). Вложенные запросы, которые используются для 
извлечения кода студента и кода предмета, в общем случае, возвращают 
множество значений. Хотя в таблице предметов название предмета явля- 
ется уникальным столбцом, второй вложенный запрос может возвратить 
пустое множество при отсутствии предмета с названием Математика”. 
Поэтому применение операции ПМ в данной ситуации является правиль- 
НЫМ. 

Еще один пример. Пусть требуется выяснить средний балл всех сту- 
дентов по фамилии Иванов. Логика рассуждений та же, что и в предыду- 
щем случае — сначала найти коды Ивановых, а затем выполнить всю ос- 
тавшуюся работу, используя только таблицу оценок: 

ЗЕГЕСТ сой $, АУС (таг) ау?_ тай ЕВОМ тагкѕ 
ҰНЕВЕ соа $ ПМ 

(ЅЕГЕСТ соа $ ЕКОМ ѕіцйепіѕ НЕВЕ пате $(=° Иванов”) 
СКОТР ВУ соа $! 


Вложенные запросы в условиях отбора (ЖУНЕКЕ и НАУ!ГХС) 

Эти запросы по своей логике ничем не отличаются от запросов, при- 
веденных выше, поэтому просто приведем примеры. 

Пусть требуется вывести фамилии самых молодых студентов (т.е. 
тех, у которых самая поздняя дата рождения). Этот запрос состоит из 
двух этапов: сначала нужно найти самую позднюю дату рождения (эту 
задачу решит вложенный запрос), а затем всех студентов, которые имеют 
найденную дату рождения. 

ЅЕГЕСТ пате $1 ЕКОМ зшеш$ \/НЕВЕ богп= 
(ЅЕЕСТ МАХ огл) ЕКОМ ѕірйепіѕ) 

Здесь знак равенства в условии \/НЕКЕ уместен, поскольку вложен- 
ный запрос гарантированно возвратит одно непустое значение, если в 
таблице $4еп имеется хотя бы одна строка (на пустой таблице этот 
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запрос также корректно работает, возвращая сообщение «строки не вы- 
браны»). 

Следующий пример несколько объемнее, но использует ту же логи- 
ку разбиения задачи на несколько этапов. 

Пусть требуется найти студентов, которые имеют максимальный (или 
минимальный) средний балл. Запрос, который находит максимальный 
средний балл студента, приводился выше, осталось только продолжить 
логику рассуждений. Зная максимальный средний балл, по таблице оценок 
можно найти коды студентов, имеющих такой средний балл (здесь потре- 
буется использование фразы НАУПМО), а по кодам студентов в самом 
внешнем запросе можно отыскать в таблице студентов их фамилии. 

В результате получили «многоэтажный», но довольно простой по 
логике, запрос: 

ЅЕГЕСТ пате 5 ЕКОМ $4еп \/НЕВЕ соа 5 ПМ 
(ЗЕГЕСТ соа 51 ЕВОМ такѕ СВООР ВУ сой 5 НАУІЧС АУС(тагк)= 
(ЗЕГЕСТ МАХ(аур так) тах аур так ЕВОМ 
(ЗЕГЕСТ АУС (шаг) аур так ЕКОМ тагкѕ СКООР ВУ соа $ 
) 
) 
) 


Вложенные запросы в качестве вычисляемых столбцов 

Такое использование вложенных запросов приводит к очень инте- 
ресной конструкции 
ЗЕГЕСТ ...(ЗЕГЕСТ ...) ЕКОМ ... 

Она поддерживается большинством СУБД. 

В качестве примера приведем задачу вычисления средних баллов всех 
студентов, для которой уже было представлено несколько вариантов за- 
просов. Приведем еще один, не самый эффективный, но правильный. 
ЗЕГЕСТ соа $, пате $, 

(ЗЕГЕСТ АУС(тагк) ЕКОМ таз \/НЕКЕ соа ѕ(=ѕ(иаепіѕ.соа $0) 

ауе та 

ЕКОМ задет 

В данном примере ау? тагк является вычисляемым столбцом, для 
которого в качестве выражения используется вложенный запрос, гаран- 
тированно возвращающий одно значение для каждой строки внешнего 
запроса. 

В последнем приведенном примере можно обратить внимание на 
одно важное обстоятельство. Вложенный запрос, использующий только 
одну таблицу тагкѕ, тем не менее, содержит во фразе \УНЕВЕ столбец из 
другой таблицы ѕіџӣепіѕ.тагк. 
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Дело в том, что таблица $4еп используется во внешнем запросе, 
поэтому ее данные разрешено использовать и во всех вложенных запро- 
сах. Обсудим эту проблему подробнее. 


Кореллированные и некореллированные вложенные запросы 

Вложенные запросы, которые не используют данных внешнего за- 
проса, называются некореллированными. Все приведенные ранее приме- 
ры, кроме самого последнего, содержали некореллированные вложенные 
запросы. Такие вложенные запросы выполняются один раз и их результа- 
ты используются во внешнем запросе в качестве констант. 

Некореллированные вложенные запросы в большинстве случаев не 
приводят к снижению производительности, если их использовать акку- 
ратно. 

Совсем иначе дело обстоит с запросами, которые используют дан- 
ные внешнего запроса. Такие запросы называются кореллированными. 
Особенность кореллированных запросов состоит в том, что они выпол- 
няются для каждой строки внешнего запроса. Это приводит к существен- 
ным затратам времени, поэтому в документации к различным СУБД при- 
водятся рекомендации использовать кореллированные запросы только в 
случае крайней необходимости. 

Тем не менее, раз такая возможность в языке ЗОГ, имеется, пользо- 
ваться ею можно, но с предельной осторожностью. 

В следующих разделах будет приведено несколько примеров корел- 
лированных запросов и показано, как можно решить те же задачи более 
эффективными способами. 


Использование ключевых слов АТГ. и АМУ с вложенными запросами 
Конструкции АТ1І(ЅЕГЕСТ ...) и АМУ(ЗЕГЕСТ...) применяются к вло- 
женным запросам, возвращающим множество строк, употребляются, 
как правило, во фразах \/НЕКЕ и НАУПМС, и означают буквально сле- 
дующее: 

АГЛ, (ЗЕГЕСТ...) – все строки вложенного ЗЕГЕСТ 

АМҮ (ЗЕГЕСТ...) – хотя бы одна из строк вложенного ЗЕГЕСТ 

В некоторых случаях употребление этих слов позволяет сформули- 
ровать запрос просто и точно. 

Проиллюстрируем это на примере. Пусть требуется вывести студен- 
тов, у которых все оценки — только четверки (никаких других оценок 
нет). Использование ключевого слова А11, позволяет решить эту задачу 
«в лоб»: 

ЗЕГЕСТ соа ѕ, пате $1 ЕКОМ зе 
ҰНЕВКЕ 4= АТІ(ЅЕГЕСТ тагк ЕКОМ тагкѕ МНЕВЕ 
сой ѕ(=ѕ(иаепіѕ.соа 50) 
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Если же требуется найти студентов, у которых имеется хотя бы одна 

четверка, можно прибегнуть к помощи ключевого слова АМУ: 

ЗЕГЕСТ соа ѕі,пате 5 ЕКОМ задет 

\НЕКЕ 4=АМУ(ЗЕГЕСТ тагк ЕКОМ тагкѕ \НЕКЕ 
сой ѕ=ѕ(0аепіѕ.соа $1) 

К сожалению, в данных примерах получились кореллированные 
вложенные запросы, так что прозрачность формулировок запроса идет в 
ущерб производительности. 

Можно привести примеры более эффективных запросов, решающих 
те же самые задачи. 

Например, чтобы найти студентов, у которых все оценки — четверки, 
достаточно сообразить, что у таких студентов и минимальная, и макси- 
мальная оценки равны 4: 

ЗЕГЕСТ ѕі.соа $, $1. пате 51 ЕВОМ зе 56 тагкѕ тт 
\НЕВЕ ѕісой 5(= т.сой 51 

СВООР ВУ т.соа $ї 

НАУІМС МІМ(т.тагкѕ)=4 АМО МАХ(т.тагкѕ)=4 

А найти студентов, у которых есть хотя бы одна четверка, можно, 
например, таким запросом: 

ЅЕТЕСТ ОІЅТІМСТ ѕісоа 5, ѕ пате 51 ЕКОМ ѕіџепіѕ $, тагкѕ т 
\НЕВЕ ѕі сой 5і= т.со4_$ АМР” т.тагк=4 


Функция ЕХІЅТЅ 
Эта функция служит для проверки результатов вложенного запроса 

на пустоту. 

ЕХІЅТЅ(ЅЕГЕСТ...) возвращает значение «истина», если вложенный ЭЕ- 

ГЕСТ возвращает хотя бы одну строку, и «ложь» в противном случае. 
Функция МОТ ЕХГЗТ$ (ЗЕГЕСТ ...) противоположна функции ЕХТУТ®. 
Например, пусть требуется вывести всех студентов, у которых нет 

оценок. 

ЗЕГЕСТ соа $, пате $1 ЕКОМ ѕёоаепіѕ 

\НЕКЕ МОТ ЕХІЅТЅ 

(ЗЕГЕСТ соа 5 ЕКОМ тагкѕ НЕВЕ соа ѕі=ѕіойепіѕ.соа ѕї) 
Приведенный текст запроса прост для понимания, но есть способы 

решить ту же задачу более эффективно, используя некореллированный 

вложенный запрос: 

ЗЕГЕСТ соа $, пате $1 ЕКОМ зе 

\НЕКЕ соа $ МОТ ТЧ 

(ЗЕГЕСТ РІЅТІМСТ соа 5 ЕКОМ так) 

или внешнее соединение таблиц: 

ЗЕГЕСТ ѕі.соа $, 51. пате $1 ЕКОМ ѕіџаепіѕ $ 

ГЕЕТ ЈОІМ тагкѕ т ОМ 56.604 ѕ(=т.соа $ 

ҰНЕВЕ т. тагк 1$ МЛЛ, 
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4.4.4. Комбинированные запросы 


Над результатами запросов можно выполнять обычные операции над 
множествами. 

Эти операции выполняются только над запросами, которые возвра- 
щают одинаковое количество столбцов одинакового типа. 

Стандартом установлены следующие обозначения для операций: 
ОМОМ [АШ ]-объединение запросов 
ПУТЕВЗЕСТ [А1 -пересечение запросов 
ЕСХЕРТ (МТМО в ОгасІе) [АТЛ - разность запросов 

Ключевое слово А11. в данном контексте запрещает удаление дуб- 
ликатов из результатов операций (тем самым повышается эффективность, 
поскольку удаление дубликатов – достаточно медленная операция). 
ЗЕГЕСТ пате 5 ЕКОМ $4еп$1 
ОМОМ АШ //всех однофамильцев, не удаляет дубликаты 
ЅЕГЕСТ пате $1 ЕКОМ $в4еп$2 
//если нет а удалит всех однофамильцев!! 


ЗЕГЕСТ пате 5 ЕКОМ ѕойепіѕ1 
ПУТЕВЗЕСТ //выводит только однофамильцев 
ЗЕГЕСТ пате 51 ЕКОМ ѕіоаепіѕ2 


ЗЕГЕСТ пате $ ЕКОМ ѕіџйепіѕ1 
МІМО //все ѕіџӣепіѕ1 если ни один не входит в ѕіџйепіѕ2 
ЗЕГЕСТ пате 5 ЕКОМ ѕіоаепіѕ2 


4.5. Представления (МІЕМ) 
4.5.1. Понятие представления 


Представления (другие варианты перевода – просмотры, виды) - это 
именованные запросы на выборку, сохранённые в БД, которые при любом 
обращении к ним по имени создают виртуальную таблицу, наполняя ее 
актуальными данными из БД. 

Для того чтобы лучше понять, для чего нужны представления и как 
они работают, сначала рассмотрим, как СУБД обрабатывает обычный 
ЅОГ.-запрос на выборку. Схематическое изображение этого процесса при- 
ведено на рис. 4.2. 
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сервер клиент 


текст запроса 


оптимизатор 
запроса 


план исполнения 
запроса 
процессор БД 
выходная 
таблица 


Рис.4.2. Порядок обработки 5ОГ-запроса ЅЕ.ЕСТ .... 


клиентское 
приложение 


Исходный текст запроса, переданный по сети из клиентского прило- 
жения, сначала подвергается проверке на правильность всех синтаксиче- 
ских конструкций и наличие всех таблиц и столбцов с именами, заданны- 
ми в тексте запроса. Для запроса, который признан правильным, затем 
формируется план его исполнения, представляющий собой описание (во 
внутреннем формате СУБД) наиболее оптимального способа реализации 
тех реляционных операций, которые содержатся в тексте запроса. Все эти 
действия выполняет специальный компонент СУБД, который называется 
оптимизатором запроса (Опегу ОрИпитег), а сам этап формирования 
плана исполнения запроса называют компиляцией по аналогии с первым 
этапом обработки программы, написанной на любом языке програмиро- 
вания. Правда, план исполнения запроса не является объектным кодом, 
который формирует компилятор с языка Разса| или С. 

Оптимизатор запроса передает план исполнения запроса другому 
компоненту СУБД, который называется процессором базы данных (или 
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процессором 501). Процессор БД исполняет все необходимые действия 
по извлечению и обработке данных. В результате формируется таблица с 
выходными данными, которая возвращается клиенту в ответ на его за- 
прос. 

Запросы на выборку, которые необходимо выполнять регулярно, нет 
смысла пересылать по сети и компилировать каждый раз, как только кли- 
енту потребуется соответствующая выборка данных. Разумно постоянно 
хранить в базе данных тексты таких запросов вместе с планами их испол- 
нения. 

Может возникнуть вопрос, зачем хранить исходные тексты запросов, 
а не ограничиться только планами их исполнения? Дело в том, что при 
наличии исходного текста имеется возможность перестройки плана ис- 
полнения запроса, если старый план окажется уже не самым оптималь- 
ным (во всяком случае, СУБД ОгасІе такую возможность поддерживает). 

К сожалению, подробный анализ работы оптимизатора запросов не 
входит в рамки настоящего курса. Самое главное, что требуется уяснить, 
- то, что представление не содержит никаких данных, в отличие от табли- 
цы, но с точки зрения клиентского приложения представление почти ни- 
чем не отличается от таблицы. Точнее, представление является виртуаль- 
ной таблицей, с которой в большинстве практических применений можно 
работать так же, как с реально существующей на диске таблицей. 

Сказанное означает, что во всех запросах на выборку ЗЕГЕСТ мож- 
но использовать имя представления везде, где можно использовать имя 
таблицы (т.е. при формулировании запросов на выборку пользователь 
может даже не знать, чем он пользуется — таблицей или представлением). 
Более того, некоторые представления (но не все) можно использовать 
даже в запросах ІЧЅЕВТ, РЕГЕТЕ и ОРРАТЕ, при этом будут внесены 
соответствующие изменения в реальные таблицы. 

Использование представлений имеет глубокий смысл, который фор- 
мулируется в правиле №7 Кодда для реляционных баз данных: 

«База данных должна быть доступна конечным пользователям толь- 
ко через представления». 

Иными словами, механизм представлений позволяет предоставлять 
каждому пользователю только ту часть базы данных, которая ему дейст- 
вительно требуется для работы (внешнюю схему), скрывая от многочис- 
ленных пользователей концептуальную схему, доступную только адми- 
нистратору базы данных. 

Для разработчика использование представлений упрощает разработ- 
ку сложных $01 -запросов, которые можно строить на основе представ- 
лений и отлаживать по частям. 

Однако не следует злоупотреблять замечательными возможностями, 
которые предоставляют представления. Не следует забывать, что для ма- 
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териализации представлений всегда выполняется ЗОГ.-запрос, на выпол- 
нение которого требуется время. 


4.5.2. Создание и удаление представлений 


Поскольку представление является объектом базы данных, для его 
создания используется стандартная команда языка РОГ, СВЕАТЕ... 
СВЕАТЕ УГЕУ имя [(список столбцов)] 

АЗ 
ЗЕГЕСТ ...// любой запрос на выборку 

Команда проста, поскольку все, что нужно для создания представле- 
ния — его имя и запрос на выборку, который лежит в основе данного 
представления. Список столбцов представления должен быть указан явно, 
если в запросе присутствуют вычисляемые столбцы без указания псевдо- 
нима. В остальных случаях столбцы представления получат такие же 
имена, как используемые в запросе столбцы таблиц. Все же рекомендует- 
ся задавать список столбцов в явном виде. 

Например, создадим представление, содержащее столбцы «код сту- 
дента, фамилия студента, его средний балл» : 

СКВЕАТЕ УТЕ\/ $4_ так (сой $, пате $, аус таг) 
АЗ 

ЗЕГЕСТ ѕі.соа $, $6. пате $1, АУС(т.тагк) 

ЕКОМ ѕаепіѕ $ _ЕЕТ ЛОГ тагкѕ т 

ОМ ѕісой ѕі=т.соа $1 

СВООР ВУ ѕі.сой 5, 51. пате $ 


При создании представления пользователю не возвращается вирту- 
альная таблица, которую он обычно получает при выполнении ЗЕГЕСТ... 
Вместо этого он получит лаконичное сообщение типа «Представление 
создано». 

Для того, чтобы материализовать представление, т.е. получить дан- 
ные в виде виртуальной таблицы, необходимо выполнить запрос ЗЕГЕСТ 
к представлению так же, как к обычной таблице: 

ЗЕГЕСТ * ЕКОМ $194 так 

Можно написать и любой другой запрос на выборку к представлению: 
ЗЕГЕСТ соа 51, аус тагк ЕКОМ 54 тагк 

\НЕКЕ соа ${=123 


Удаляется представление также стандартными средствами РОГ: 
ОВОР УІЕҰ имя представления 

Выполнив последовательно команды ОВОР УТЕХ..., а затем снова 
СВЕАТЕ МІЕ№ ... с тем же самым запросом ЗЕГЕСТ, мы не напрасно 
потеряем время. Во многих случаях СУБД сформирует новый план ис- 
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полнения того же самого запроса в соответствии с изменившимся напол- 
нением таблиц или появлением новых индексов. Это приведет к сокра- 
щению времени материализации представления. 

СУБД Огае позволяет изменить план исполнения запроса без уда- 
ления представления, используя команду: 
АГТЕВ УТЕУ имя КЕСОМРІШЕ 


4.5.3. Обновление представлений 


На некоторые представления можно писать запросы ОР”РАТЕ, РЕ- 
ГЕТЕ и ПХЗЕКТ, как на обычные таблицы. При выполнении таких за- 
просов реально все изменения вносятся в физические таблицы. 

Такие представления называются обновляемыми. Согласно стандар- 
ту ЗОГ, обновляемыми являются представления, основанные на запросах: 

1) только по одной таблице 

2) запрос не должен содержать ключевых слов ОТЗТИМСТ, СВОЧР 
ВУ, НАУІМО 

3) не должен содержать вложенных запросов 

4) не должен быть комбинированным, т.е. не должен содержать 
операций ОМІОМ, ПУТЕВЗЕСТ, ЕХСЕРТ (МПМО5). 

Отасе, дополнительно, не позволяет обновлять запросы с сортиров- 
кой результатов. 

Таким образом, обновляемых представлений не так и много: 
® представления с отбором столбцов (вертикальные представления) 

представления с отбором строк (горизонтальные представления) 
представления с отбором строк и столбцов (смешанные представле- 
НИЯ). 

Например, создадим горизонтальное представление на основе выбор- 
ки из таблицы оценок тагкѕ, содержащее только оценки по Математике. 

Предварительно мы выяснили из таблицы предметов ѕирјесіѕ, что 
математика имеет код 1. 

Тогда для создания представления потребуется выполнить команду: 
СВЕАТЕ УПЕУ/ тагк 1 
АЗ 
ЗЕГЕСТ * ЕВОМ тагкѕ 
ҰМНЕВЕ соа _5и6=1 

Это представление будет обновляемым, поэтому преподаватель ма- 
тематики, которому разрешено обновление этого представления, может 
изменить любую (одну) оценку, например, таким запросом: 

ОРБАТЕ тагк 1 ЅЕТ тагк=5 \/НЕВЕ соа 5=123 

Однако запрос: 

ОРРАТЕ так 1 ЅЕТ сой 5а6=2 МНЕКЕ соа 5=123 
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который также, как и первый, является разрешенным, приведет к неожи- 
данным последствиям. Обновленная строка окажется за пределами пред- 
ставления тай 1 и запрос: 

ЗЕГЕСТ * ЕВОМ тагк 1 

эту строку не покажет. 

Если такой побочный эффект нежелателен, в команду СВЕАТЕ 
УПГЕ\М/ ... следует добавить дополнительную фразу МІТН СНЕСК ОР- 
ТОМ: 

ОБВОР МІЕҸУ тагк 1 

СВЕАТЕ МЕМ так 1 

АЗ 

ЅЕГЕСТ * ЕВОМ тагкѕ НЕВЕ со4_$и6=1 
УЛТН СНЕСК ОРТІОМ 

Теперь при любой попытке изменить код предмета или добавить 
предмет с кодом, отличным от единицы, будет выдано сообщение об 
ошибке. 

Если говорить о данном конкретном примере, то можно было бы по- 
ступить еще проще: не включать столбец сой 516 в представление, тогда 
у преподавателя математики просто не будет никакой возможности изме- 
нить (нечаянно или преднамеренно) код своего предмета. 


4.5.4. Стандартные представления словаря данных 
Огас!е 


Напомним, что словарь данных СУБД - это совокупность служеб- 
ных таблиц, в которых хранится исчерпывающая информация обо всех 
объектах базы данных (метаданные). Доступ к словарю данных Огас!е 
осуществляется только через представления, названия которых форми- 
руются по определенным правилам: 

аба название (служебная информация для АБД) 

уѕег название (информация об объектах конкретного пользователя) 

аП_ название (полная информация) 
Примеры представлений: 

15ег 1а01еѕ (информация о таблицах) 

и5ег_\1е\$ (информация о представлениях) 

и5ег реет (информация о триггерах) 

аба _изет$ (имена пользователей) 

а] објесіѕ (информация обо всех объектах) 

Например, с помощью команды 

ЅЕГЕСТ (абе пате ЕКОМ оиѕег {а ез 

можно получить имена всех таблиц, созданных конкретным пользова- 
телем. 
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Особо хочется отметить представление изег_еггог$, которое содер- 
жит сведения об ошибках, полученных при компиляции хранимого кода. 
Оно будет использоваться в следующей лекции. 


4.6. Хранимый код. Триггеры 
4.6.1. Процедурные расширения языка $501 


Как мы показали в предыдущих лекциях, язык 501. является очень 
мощным языком манипулирования данными, однако для решения слож- 
ных задач обработки данных ему не хватает управляющих конструкций, 
имеющихся в универсальных языках программирования. В связи с этим 
многие СУБД имеют процедурные расширения этого языка, которые 
представляют собой полноценный язык программирования, поддержи- 
вающий возможность использования в нем операторов ЗОГ. На таком 
языке можно писать процедуры и функции, постоянно хранящиеся в базе 
данных и исполняемые в среде СУБД. 

К сожалению, на настоящий момент ситуация такова, что каждая 
СУБД поддерживает свой собственный язык процедурного расширения 
ЗОГ, что усложняет задачи переносимости программного обеспечения. 
Поэтому те примеры, которые будут приведены в этой лекции, использу- 
ют процедурный язык РГ/ЗОГ, поддерживаемый Отасіе, и работают толь- 
ко в среде этой СУБД. Из других процедурных расширений наиболее 
близок к РГ/ЗОГ, язык СУБД РоетеЗ ОГ, который называется РЕС/ЗОГ. 
Используемое в Місгоѕоћ ЗОГ, Зегуег процедурное расширение Ттапѕасі- 
ЗОГ. по синтаксическим конструкциям отличается от РГ/ЗОГ, но по се- 
мантике является близким. Во всяком случае понимание логики разра- 
ботки хранимого кода на РГ./ЗОГ, поможет легко освоить и любое другое 
процедурное расширение. 

Для дальнейшего изложения необходимо привести минимальные 
сведения по конструкциям языка РГ/ЗОГ. По синтаксису он наиболее 
близок языку программирования АРА, конструкции его очень логичны. 
Основной программной единицей является блок — совокупность операто- 
ров, заключенная в операторные скобки ВЕСІМ ... ЕМ”. При выполнении 
процедурных действий в блоке, как правило, необходимы переменные 
для хранения промежуточных значений. Объявление переменных пред- 
шествует блоку и образует секцию объявления, которая начинается клю- 
чевым словом РЕСГАКЕ. Для переменных поддерживаются те же типы, 
что и для столбцов таблиц ОгасІе. Имеется возможность указать тип пе- 
ременной, явно ссылаясь на определенный столбец или таблицу. 
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Например: 
РЕСГАВЕ 
х ПМТЕСЕК; 
По ие. пате 51%ТҮРЕ; 
$ $16] ес{5% ТУРЕ; 
ВЕСІМ 
ЕМ” 

В приведенном примере для переменной х тип указан явно, пере- 
менная бо имеет такой же тип, как столбец пате $ таблицы ѕіџйепіѕ, пе- 
ременная $ имеет тип запись (ВЕСОКО), структура которой идентична 
строке таблицы зи ]ес{5 (содержит два поля со4_516 и пате $16). 


Операторы языка РУЗОЁ 


1. Оператор присваивания 
переменная:= выражение; 


2. Условный оператор 
ІЕ условие ТНЕМ 
оператор1; оператор2; 


[Е1.5ІЕ условие ТНЕМ 
оператор3; оператор; 
... 

[ЕТЗЕ 
оператор5; операторб; 
... 

ЕМО ІЕ; 


3. Операторы цикла 
Бесконечный цикл, условие выхода задается в теле цикла 
ГООР 

операторі; оператор2; 


ЕХІТ ҰНЕМ условие выхода из цикла; 
ЕМ№” ГООР; 


Цикл с предусловием 
М\НШЕ условие ГООР 
оператор1; оператор2; 


ЕМ” 1.ОФР: 
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Цикл с параметром 
ЕОК параметр ПМ (множество значений) ГООР 
оператор1; оператор2; ... 
ЕМ” ГООР; 
Множество значений параметра обычно задается в виде диапазона 
(начальное значение .. конечное значение) 


5. Оператор безусловного перехода: 
СОТО метка; 


метка: оператор; 


6. Оператор возврата из процедуры/функции 
ВЕТОВМ; 
ВЕТОВМ выражение; (только функции) 


7. Комментарии 
Однострочный комментарий обозначается так: 
-- далее следует текст комментария до конца строки 
Многострочный комментарий обозначается аналогично языку С: 
/* текст комментария может располагаться где угодно и занимать сколько 
угодно строк */ 


8. Средства для обработки исключительных ситуаций 

Общий подход к обработке исключительных ситуаций состоит в 
том, что для каждой ситуации определяется ее обработчик и при возник- 
новении ситуации выполняется код обработчика. 

В РГ/ЗОГ предусмотрена возможность как обрабатывать стан- 
дартные ситуации, так и вводить собственные исключительные ситуа- 
ции. Предусматриваются также средства генерации исключительных 
ситуаций. 

Для стандартных исключительных ситуаций существует большое 
число предустановленных имен. Пользовательская исключительная 
ситуация вводится объявлением переменной типа ЕХСЕРТІОМ. 
Генерация исключений из программы выполняется в РГ/ЗОГ, операто- 
ром ВАТЅЕ. 

Обработчик исключений в РЕ/ЗОГ,, общий для всех исключений, со- 
ставляет отдельную часть блока РІ/501, начинающуюся со слова 
ЕХСЕРТІОМ№ и содержащую набор операторов МНЕМ, распознающих 
типы исключений и задающих действия, выполняемые по каждому типу 
(возможны любые действия, которые можно запрограммировать средст- 
вами РЕ/ЗОГ.). 
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Например: 

РЕСГАВЕ 

ет ЕХСЕРТІОМ; 
ВЕСІ 
ПУЗЕВТ ІМТО ... УАШЈЕЅ ...; 
ЗЕГЕСТ ... ПУТО ...; 

ГЕ... ТНЕМ 

ВАГЗЕ етт; 


ЕХСЕРТІОМ 

ҮНЕМ РОРИСАТЕ_КЕУЗ ТНЕМ 
ҰҮНЕМ ТОО МАМ№Ү ВО\!$ ТНЕМ 
ХҮНЕМ ет ТНЕМ 

ҮНЕМ ОТНЕВЅ ТНЕМ 


ЕМО; 

В приведенном примере имеется два предопределенных имени для стан- 
дартных исключительных ситуаций, возникающих в процессе выполне- 
ния команд ПМЗЕВТ и ЗЕГЕСТ ...ПУТО и предопределенное имя ОТН- 
ЕВ$, предназначенное для обозначения любой другой исключительной 
ситуации, которую процедура отдельно не обрабатывает. Переменная ет 
предназначена для возбуждения пользовательской исключительной си- 
туации при помощи оператора КАТЗЕ. 

Как видим из приведенного примера, блок РГ./ЗОГ, может содержать ко- 
манды языка 501, которые органично сочетаются с операторами языка 
высокого уровня. Эта тема заслуживает отдельного обсуждения, посколь- 
ку механизм встраивания команд в язык высокого регламентируется 
стандартом ОГ. и практически одинаков во всех СУБД. 


4.6.2. Использование команд $01 в хранимом коде 


Команды ПУЗЕКТ, ОЕГЕТЕ и ОРРАТЕ используются в программе 
на РЕ/ЗОГ, в качестве отдельных операторов наряду с другими операто- 
рами языка. В данных командах разрешено использовать переменные 
программы везде, где по правилам 501. используются константы, что де- 
лает данные команды более гибкими, чем при их использовании в инте- 
рактивном режиме. Для обработки исключительных ситуаций, которые 
могут возникнуть в случае, когда какая-либо из этих команд нарушает 
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целостность данных, существует большое количество стандартных пре- 

допределенных имен. Например, приведенная в предыдущем примере 

ситуация РОРЫСАТЕ КЕУЗ возникает при нарушении ограничения 
уникальности (и в первичном ключе в том числе). 

Проблема возникает при встраивании в процедурный язык оператора 
ЗЕГЕСТ. Результатом оператора ЗЕГЕСТ является множество строк, а 
процедурный язык ориентирован в основном на обработку последова- 
тельностей. Для преодоления этого противоречия в стандарт 501. введен 
механизм курсора, который реализован и в РГ./ЗОГ, Огасе. Курсор пред- 
ставляет собой результат выборки из базы данных, который предназначен 
для дальнейшей построчной обработки. 

Различают неявный и явный курсоры. Неявный курсор можно ис- 
пользовать только в том случае, если запрос на выборку возврашает ров- 
но одну строку. Тогда этот результат можно поместить в обычные пере- 
менные, используя расширенный синтаксис команды ЗЕГЕСТ: 

ЅЕГЕСТ список выражений ІЧТО список переменных ... 

остальная часть оператора ЗЕГЕСТ 

Количество переменных в списке и их типы должны в точности со- 
ответствовать списку выражений оператора ЗЕГЕСТ. 

ЗЕГЕСТ так ІЧТО мт ЕКОМ шайб \УНЕКЕ сой ѕі=с 51 АМО 

сой ѕир=с 5 

Значения переменных с_$ и с $ задаются заранее. Если существуют 
студент и предмет с такими значениями кодов, запрос вернет ровно одно 
значение оценки и разместит его в переменной с именем т. 

При выполнении команды ЗЕГЕСТ ... ІЧТО ... в различных случаях 
ее применения могут возникнуть две разные исключительные ситуации: 

е ТОО МАМУ КОМЗ возникает в том случае, если запрос ЗЕГЕСТ 
вместо одной строки возвращает несколько строк (в этом случае воз- 
вращаемые данные невозможно разместить в заданном списке пере- 
менных) 

»® МО РАТА ҒООМР” возникает в том случае, если запрос ЗЕГЕСТ 
вообще не возвращает данных. Тогда переменные в списке не могут 
получить никаких значений. 

При наличии обработчиков для каждой из указанных ситуаций при- 
менение неявного курсора является простым и вполне безопасным спосо- 
бом обработки результатов однострочной выборки из базы данных. При- 
меры практического использования данной конструкции мы приведем в 
следующем разделе. 

Явный курсор является более универсальным средством обработки 
произвольной выборки из базы данных. Он должен быть явно объявлен в 
разделе РЕСГАВЕ. В объявлении курсора определяется его имя и запрос, 
на котором он основан. 
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РЕСГАКЕ СОВЅОВ имя курсора 15 ЗЕГЕСТ ...далее идет запрос на вы- 
борку 

Например: 

РЕСГАВЕ СОКЅОК сиг [$ 
ЅЕГЕСТ пате $1 ЕКОМ зшаеп($ \/НЕВЕ пате $ КЕ ‘А%’ 

Следует отметить, что приведенное выше объявление курсора, при- 
нятое в ОгасІе, не совсем соответствует стандарту. Согласно стандарту 
объявление курсора выглядит так: 
имя курсора СОКЅОК РОК ЅЕГЕСТ .... 

Все остальные операции с курсором соответствуют стандарту. 

Объявление курсора не является выполнимым оператором. Выборка, 
заданная в объявлении курсора, выполняется только при его открытии. 

Например: 

ОРЕМ СОКЅОК сш 
После открытия курсора можно последовательно выбирать строки курсо- 
ра, используя оператор ЕЕТСН. Например: 

ЕЕТСН сиг ІМТО Во 

Переменная бо должна быть предварительно объявлена, например, так: 
Но ѕёоӣепіѕ. пате 5% ТҮРЕ; 

Каждое следующее выполнение ЕЕТСН выбирает значение столбцов 
из следующей строки выборки в переменные заданного списка. Оператор 
ЕЕТСН, как правило, применяется в цикле. Например: 

ГООР 
ЕЕТСН сиг ІЧТО Во; 


ЕХІТ УНЕМ МОТ сш%ЕООМР; 
ЕМ” ООР; 
ИЛИ 
ЕЕТСН сиг МТО во; 
\УНЦШЕ сш%ЕООМР” ГООР 
ЕЕТСН сиг МТО По; 


ЕМ” ГООР; 
После того, как выбраны все нужные строки, курсор должен быть закрыт. 
Например: 

СГОБЕ сог 


Цикл по курсору 
Некоторые СУБД, в том числе ОгасІе, поддерживают цикл с параметром 


но курсору; 
ЕОК параметр ПМ имя курсора ГООР 
ЕМО ГООР: 
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Использование такого цикла не требует операций открытия и закры- 
тия курсора – они выполняются неявно. Параметр цикла не требуется 
объявлять в секции РЕСГАВЕ, его тип определяется автоматически как 
ВЕСОВО, а имена полей записи соответствуют именам в объявлении 
курсора. Например: 

ЕОВ сиг тес ПМ сиг ГООР 
... саг тес.пате $... 
ЕМО ГООР; 

Из этих объяснений понятно, что использование цикла по курсору — 
очень простой и удобный способ обработки курсора. 

Приведенных сведений уже достаточно, чтобы перейти к практиче- 
скому применению языка РТ./ЗОГ.. Его основное назначение — разработка 
хранимых процедур и функций, а также триггеров базы данных. 


4.6.3. Хранимые процедуры и функции 


Хранимые процедуры и функции являются стандартными объектами 
базы данных. Их понимание в 501 не отличается от общепринятого: хра- 
нимой подпрограммой (процедурой или функцией) называется именован- 
ная, отдельно описанная, повторно используемая программная единица, 
выполняющая, как правило, определенную прикладную функцию. 


Преимущества и недостатки хранимого кода 


В современных информационных системах значительная часть биз- 
нес-логики содержится в хранимом коде. Хранимые подпрограммы обес- 
печивают приложениям баз данных следующие преимущества: 

® сокращение объема программирования при разработке приложе- 
ний, так как однажды созданная подпрограмма может использо- 
ваться разными приложениями; 

• уменьшение сетевого трафика, так как, если подпрограмма вклю- 
чает в себя несколько обращений к базе данных, по сети переда- 
ется не каждый запрос и его результат, а только вызов процедуры 
и ее конечный результат; 

• повышение производительности, так как на сервере есть больше 
возможностей оптимизации локально выполняющихся запросов 
и здесь могут быть применены средства, недоступные для кли- 
ентской части; 

® гарантия того, что задача, решаемая хранимой процедурой, будет 
одинаково выполняться для всех клиентских приложений и для 
всех клиентских платформ при любых настройках клиентов. 

Основным недостатком хранимого кода является его непереноси- 
мость между различными СУБД. В силу этого, для масштабируемых ин- 
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формационных систем или систем, предназначенных для многократного 
тиражирования, часто используется трехзвенная архитектура системы с 
переносом значительной части бизнес-логики на уровень сервера прило- 
жений. Практикуется и такой вариант: серверная часть тиражируемой 
информационной системы разрабатывается сразу для нескольких самых 
распространенных СУБД (например, вариант для Огасе, РоетеЗ ОГ. и 
Місгоѕоћ 5ОГ, Зетуег). 

Следует отметить, что хранимые процедуры и функции не следует 
рассматривать как альтернативу сложным ЗОГ-запросам. По сравнению с 
«чистым» ЗОГ, любая процедурная альтернатива является худшим вариан- 
том с точки зрения производительности, поскольку ЗОГ-запросы любая 
СУБД обрабатывает с наивысшей эффективностью. Поэтому не нужно 
поддаваться соблазну и переходить на уровень процедурной логики там, 
где можно, пусть ценой больших мыслительных усилий, написать слож- 
ный, но эффективный запрос с использованием только средств языка ЗОГ. 


Создание хранимых процедур и функций 


В ОгасІе традиционно основным языком хранимых процедур являет- 
ся язык РЫ/ЗОГ, но поддерживаются и процедуры на других языках, пре- 
жде всего — на языках С++ и Јауа. В последнем случае хранимая процеду- 
ра или функция называется внешней. В рамках нашего курса рассмотрим 
основной вариант — хранимая процедура на РГ/ЗОГ.. 

Хранимая процедура создается оператором 501. 

СВЕАТЕ [ОК КЕРГАСЕ] РКОСЕРОВЕ имя[(список_параметров)| 
АЗ 
блок РЕ/ЗОГ 

Необязательная конструкция ОК КЕРГАСЕ позволяет заменять про- 
цедуру с таким же именем. Это очень удобно в процессе отладки. 

Аналогично создается хранимая функция: 

СВЕАТЕ [ОВ КЕРГАСЕ] ЕОМСТТОМ имя[(список_параметров)] 
КЕТОВМ тип результата, возвращаемого функцией 

АЗ 

блок РЕ/ЗОГ, обязательно содержащий оператор 

КЕТОАМ выражение 

В списке параметров должен быть описан режим использования ка- 
ждого параметра: ПМ (только входной — используется по умолчанию), 
ОЧОТ (только выходной), ПМ ОПТ (и входной, и выходной). Режим ис- 
пользования указывается после имени параметра. Типы параметров, как и 
типы переменных, можно указывать явно или с помощью ссылки на соот- 
ветствующий столбец или таблицу. 

При описании локальных переменных подпрограммы разрешено 
опускать ключевое слово РЕСГАВКЕ. 
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Удалить хранимую процедуру или функцию можно при помощи ко- 
манды ОВОР. 


Примеры хранимых процедур и функций 


В качестве примеров приведем две хранимые подпрограммы для 
нашей демонстрационной базы студентов и их оценок. 

Первая из процедур демонстрирует применение неявного курсора и 
предназначена для изменения телефона студента. Ее входными парамет- 
рами являются фамилия и новый телефон студента. Конечно, первым 
входным параметром должна быть не фамилия, а личный код студента, но 
таким образом мы хотим продемонстрировать исключительную ситуацию 
ТОО МАМУ КО. В случае наличия однофамильцев, а также в случае 
отсутствия студента с такой фамилией процедура должна сообщить о 
возникшей исключительной ситуации. 

Также целесообразно отдельно обработать случай, когда старый те- 
лефон совпадает с новым, поэтому операции обновления не требуется. 

Для фиксации всех перечисленных выше случаев в процедуру до- 
бавлен выходной параметр гезиК, который после завершения процедуры 
возвращает код ошибки (0 — благополучное завершение процедуры) и 
может быть обработан клиентским приложением. 


СКЕАТЕ РКОСЕРОВЕ сһапрерһопе(ћоѕіџа зиа4ет($.пате_$(%ТУРЕ, 
пеуурвопе $и4ет5.рНопе%ТУРЕ, 


теѕи ОПТ МОМВЕК) 
АЗ 
о1арвопе ѕќоӣепіѕ.рһопе%ТҮРЕ; -- старый телефон 
ВЕСІМ 


ЅЕГЕСТ рропе ІЧТО ојарћопе ЕКОМ ѕќџйепіѕ МНЕВЕ пате $=йоѕ(оа; 
ТЕ оЈјарһопе!=пеурһопе ТНЕМ 

ОРРАТЕ ѕіоаепіѕ ЗЕТ рһопе=пеурһопе МНЕКЕ пате $Е=Но$аа; 
геѕше:=0; 


ЕГЗЕ 

тезше=1; -- старый и новый номера совпали 
ЕМО ІБ; 

ЕХСЕРТОМ 


\НЕМ МО РАТА _ ЕОЧКЮО ТНЕМ -- нет такого студента 
тезии:=2; 

\НЕМ ТОО МАМУ ВОМ ТНЕМ 

тези:=3; -- есть однофамильцы 


ҮНЕМ ОТНЕВ$ ТНЕМ 
тези:=4; -- непредвиденная исключительная ситуация 
ЕМ”; 
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Выполнив команду создания данной процедуры в ЗОГ*Р!$, мы по- 
лучим сообщение «Процедура создана». В случае, если в процедуре обна- 
ружены синтаксические ошибки, выдается другое сообщение «Процедура 
создана с ошибками компиляции». Получить информацию об обнаружен- 
ных ошибках можно с помощью запроса к представлению словаря Огас!е 
изег еггоге: 

ЗЕГЕСТ Нпе, {ех{ ЕВОМ изег_ етгогѕ 

Хранимая процедура запускается на выполнение по команде из кли- 
ентского приложения. 

Чтобы запустить ее на выполнение из ЗОГ.*Р1а$ в целях отладки не- 
обходимо поместить ее в блок РГ./ЗОГ, перед которым объявить пере- 
менную для выходного параметра: 

УАВ е МОМВЕК; 
ВЕСІМ 
сһапрерһопе("Иванов!, '555555', :е); 


Проверить значение переменной е можно при помощи команды: 
РВІМТ е 


В качестве второго примера приведем функцию, которая принимает 
в качестве входного параметра фамилию студента и возвращает строку, 
содержашую телефоны всех студентов с такой фамилией (возможно, пус- 
тую строку, если студентов с такой фамилией нет). Здесь демонстрирует- 
ся применение явного курсора. 
СКЕАТЕ ЕОМСТЮОМ реірһопе (һоѕіџа ѕіойепіѕ. пате 51%ТҮРЕ) 
ВЕТОВМ УАВСНАВ 
АЗ 
СОБВЗ$ОК с 15 
ЅЕГЕСТ рһопе ЕКОМ зе 
ҰНЕВЕ пате 5(= Поза; -- телефоны всех студентов с заданной фами- 
лией 
геЅ УАКСНАК (50); -- строка результата 
рћ ѕоаепќѕ.рһопе% ТҮРЕ; -- переменная для команды ЕЕТСН 
ВЕСІ 
ОРЕМ с; 
теѕ:="; 
ГООР – цикл для извлечения данных из курсора 
ЕЕТСН с ІМТО р; 
ЕХТ МНЕМ МОТ с%ЕОЧМР; 
теѕ:=геѕ|ірђ|' '; 
ЕМ” ГООР; 
КЕТОКМ гез ; 
ЕМО; 
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Если использовать цикл по курсору, тело функции получится короче: 

ВЕСІМ 

теѕ:="; 

РОБ стес ПМ с ГООР 

теѕ:=теѕ||стес.рһопе|! '; 

ЕМ” ГООР; 

ВЕТОКМ геѕ ; 
ЕМО; 
После создания функции проверить ее работоспособность можно совсем 
просто: 
ЅЕГЕСТ реірһопе("Иванов') ЕКОМ аџаІ 


4.6.4. Триггеры 


Триггеры – особый вид хранимых процедур, которые запускаются 
автоматически при наступлении определенных событий в базе данных. 


Особенности триггеров 


Являясь по сути хранимой процедурой, триггер обладает теми же 
преимуществами и недостатками, что и весь хранимый код. К преимуше- 
ствам следует добавить то, что триггеры являются прекрасным инстру- 
ментом для администратора БД, поскольку работают независимо от того, 
какое из клиентских приложений вызвало активизирующее их событие. 
Эта особенность превращает триггеры также в средство добавления но- 
вой функциональности в существующую систему без всякого изменения 
ее программного кода. Достаточно только выбрать подходящее событие и 
создать триггер. 

Однако, нужно отметить, что использовать триггеры следует с осо- 
бой осторожностью, ведь клиентские приложения вообще ничего не зна- 
ют о существовании тех или иных триггеров на сервере, и важно не до- 
пустить никаких конфликтов и противоречий в слаженной работе всей 
информационной системы. 

Событий, которые могут активизировать триггеры, довольно много, 
например, Огасіе поддерживает триггеры уровня базы данных, уровня 
схемы и уровня таблицы. В рамках данного курса рассмотрим только 
триггеры уровня таблицы, которые обеспечивают автоматическое выпол- 
нение некоторых действий при каждой модификации данных таблицы. 

Такой триггер характеризуется следующими признаками, которые 
должны быть заданы при его создании: 

• уникальное имя триггера (задание параметров не требуется, по- 
скольку триггер – процедура без параметров); 
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® активизирующее действие - команда, которая вызывает запуск 
триггера, такими командами являются ТМ5ЕВТ, РЕТЕТЕ, ОРРАТЕ; 

® время активизации - выполнение триггера до (ВЕРОВЕ) или по- 
сле (АЕТЕВ) выполнения активизирующего действия; 

® область действия - выполнение триггера либо один раз для каж- 
дого оператора модификации таблицы, либо для каждой строки 
(в последнем случае следует добавить фразу РОВ ЕАСН КОМ); 

• условие активизации - необязательное дополнительное условие, 
которое должно выполняться для запуска триггера (фраза 
\МНЕМ); 

е тело триггера — действия, выполняемые триггером (блок 
РІ/801). 

На каждое событие может быть создано и несколько триггеров. Од- 
нотипные триггеры выполняются в порядке их создания. 

Действие, выполняемое в триггере, может включать в себя операции 
ТМЗЕВТ, РЕЪЕТЕ, ОРРАТЕ, которые, в свою очередь, могут запускать 
выполнение того же или других триггеров. Такое явление называется кас- 
кадированием триггера. 


Команды $01 для работы с триггерами 


Триггер создается при помощи команды ЗОГ: 
СКЕАТЕ [ОК ВЕРГАСЕ] ТКІССЕК имя триггера 
время активизации активизирующая команда ОМ имя _ таблицы 
[ЕОК ЕАСН КОМ] 
[%УНЕМ дополнительное условие запуска триггера] 
А$ 
Блок РГ/ЗОГ 

В теле триггера можно использовать любые операторы РГ./ЗОГ, 
кроме операторов ЗОГ, которые изменяют ту таблицу, для которой был 
создан данный триггер. Любые другие таблицы изменять можно. 

В теле триггера в Огафе можно использовать две предопределенные 
переменные, которые обозначают ту строку, которая в данный момент 
подвергается модификации: 

МЕМ – новое значение строки, применяется для команд ІЧЅЕВТ и ОР- 
РАТЕ 

ОГО – старое значение строки (до модификации), применяется для ко- 
манд РЕГЕТЕ и ОРРАТЕ 

Если триггер благополучно создан, далее он будет запускаться сам 
при любом наступлении активизирующего события. Удалить триггер 
можно при помощи команды 
”КОР ТКІССЕК имя триггера 
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Иногда бывают ситуации, когда по каким-либо причинам автомати- 
ческое срабатывание триггера не нужно, но и удалять его нельзя, по- 
скольку в дальнейшем он потребуется. 

Для временного отключения триггера в Ога е можно применить ко- 
манду: 

АГТЕВ ТКІССЕК имя триггера ОЗАВГЕЕ 

Чтобы снова включить существующий триггер, используют команду: 

АГТЕВ ТКІССЕК имя триггера ЕМАВГЕ 


Примеры триггеров 


1. Триггер на вставку нового студента 

При вставке новой строки в таблицу триггеры часто используются 
для задания таких значений по умолчанию, которые нельзя определить 
при создании таблицы с помощью фразы РЕРАОГТ. В ОгасІе триггер на 
вставку чаще всего используется для автоматического задания значений 
первичного ключа. В стандарте 501. 2003 для этих целей имеется специ- 
альное ключевое слово ІЮЕМТІТҮ, но в ОгасІе оно не поддерживается. 

Вместо этого имеется специальный объект ЅЕООЕМСЕ, который 
предназначен для формирования последовательных целых чисел (этот 
объект зафиксировн в стандарте 501. 2003). Для обращения к значениям 
последовательности в выражении БОГ. используются псевдостолбцы 
СОВВУАІ, и МЕХТУАГ. СОВВУАГ возвращает текущее значение. 
МЕХТУАГ инкрементирует текущее значение и возвращает результат, 
при этом он становится текущим значением. Триггер на вставку берет из 
последовательности очередное значение и помещает его в новую строку, 
используя предопределенную переменную :М3ъЕМ. 

Например, создадим последовательность для формирования кодов 
студентов: 

СВЕАТЕ ЅЕООЕМСЕ ѕ0а ѕед 

Теперь создадим триггер на вставку новой строки в таблицу задет: 
СВЕАТЕ ТЕІСОЕВ 5 Кеуѕ 

ВЕЕОКЕ ІҸЅЕКТ ОМ зе 

ЕОК ЕАСН КОМ 

ВЕСІМ 

ЅЕГЕСТ $4 ѕед. МЕХТУАТ ПУТО :МЕМ сой 5 ЕКОМ ара; 

ЕМО; 

Аналогичный триггер можно написать и на таблицу ѕибјесіѕ, по- 
скольку при добавлении нового предмета его код должен формироваться 
также автоматически. Для этих целей обычно создают еще одну последо- 
вательность, хотя, в принципе и одна последовательность на все таблицы 
с суррогатными ключами обеспечит уникальность значений ключа в каж- 
дой таблице. 
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2. Триггеры на удаление студента 
Триггер на удаление должен предусмотреть перенос удаляемых дан- 
ных в архивную базу данных. При создании таблиц нашей базы данных 
вместе с удалением студента было предусмотрено и каскадное удаление 
оценок студента, поэтому мы можем написать аналогичные триггеры ВЕ- 
ЕОКЕ РЕГЕТЕ на таблицы $а4еп и тагкѕ, используя возможность кас- 
кадирования триггеров. При удалении студента одна единственная ко- 
манда удаления, полученная сервером, например: 
РЕГЕТЕ ЕКОМ задет НЕВЕ со4 5=125 
вызовет выполнение двух команд удаления (из таблиц тагкѕ и ѕіџйепіѕ) 
вместе с двумя триггерами, сохраняющими удаляемые данные в архиве. 
Предположим, что уже созданы таблицы агсШуе $4еп и 
агсшуе тагкѕ. Создадим триггер на удаление из таблицы ѕіџйепіѕ: 
СВЕАТЕ ТВІССЕА $ ае! 
ВЕҒОВЕ РЕГЕТЕ ОМ зе 
ЕОК ЕАСН ВО\У 
ВЕСІМ 
ПУЗЕКТ ІМТО агсшуе ѕёойепіѕ 
УАГОЕ$(:ОГО.со4_$, :ОГР” пате $, :ОГР бот, :ОГР .рћопе); 
ЕМО; 
Триггер на удаление из таблицы оценок выглядит аналогично, фраза 
ЕОК ЕАСН ВО\ 
вызовет его срабатывание при удалении каждой оценки студента. 


3. Триггер на изменение оценки 

Изменения, вносимые в элементы данных, которые в своей предмет- 
ной области имеют существенное значение и подлежат усиленному кон- 
тролю, обычно фиксируются в журналах изменений. В базах данных та- 
кие журналы могут представлять собой обычные таблицы и формиро- 
ваться при помощи триггеров. Триггеры, предназначенные для контроля 
изменений в важных таблицах, могут быть написаны и на вставку, и на 
удаление, и на обновление. Однако злоупотреблять этой замечательной 
возможностью все же не следует, поскольку каждый дополнительный 
триггер снижает производительность системы. 

В нашей демонстрационной базе данных, очевидно, имеет смысл 
контролировать изменение уже выставленной оценки. Поэтому создадим 
специальную таблицу сВапое тагк 109 (журнал изменений оценок), ко- 
торая будет содержать столбы: 
пате иѕег (имя пользователя, изменившего оценку) 
ааќе сһапее (дата изменения оценки) 
сой $1 (код студента) 
соа ѕиб (код предмета) 

014 так (старая оценка) 
пеуу тагК (новая оценка) 
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Теперь создадим триггер на обновление: 
СВЕАТЕ ТЕІССЕВ тагк сһапре 
АҒТЕВ ОР”АТЕ ОМ тагкѕ 
РОВ ЕАСН ВОМ 
ВЕСІМ 
ІЕ:ОГР. тагк<> :МЕМ.тагк ТНЕМ 
ПУЗЕВТ ІМТО сһапре так Іор 
УАГОЕ5(иег,  зузде, :ОГРЮ.соа $. :ОГР.соа 546, ОГО так, 
:МЕМ таг); 
ЕМО ІЕ; 
ЕМО; 


Проверка работоспособности триггера 


Для проверки работоспособности триггера нужно выполнить коман- 
ду, активизирующую триггер. 

Например, для последнего триггера, который заполняет журнал из- 
менения оценок: 

ОРРАТЕ тагкѕ ЗЕТ тагк=3 МНЕВЕ тагк=2 

Если в таблице оценок были неудовлетворительные оценки, таблица 
сһапре так Іор будет содержать исчерпывающие сведения об их изме- 
нении. Просмотреть ее администратор базы данных сможет в любое 
удобное для него время. 

Следует отметить, что вопросы создания и удаления триггеров 
обычно находятся в компетенции администратора базы данных (АБД), а 
не разработчиков прикладного программного обеспечения. В следующей 
главе мы кратко коснемся основных проблем, которые необходимо ре- 
шать АБД в процессе создания и эксплуатации базы данных, и средств, 
предоставляемых СУБД для этих целей. 
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5. Управление доступом к данным 


Цель изучения данной главы — получить основные знания и умения 
администрирования базы данных. 
После изучения главы вы будете: 
® знать основные принципы организации системы безопасности СУБД 
• уметь создавать учетные записи пользователей, присваивать им опре- 
деленные привилегии и роли 
® понимать свойства транзакций (АСИД), уметь применять на практике 
команды ЗОГ, для поддержки транзакций 
® знать основные принципы управления производительностью СУБД 
® уметь создавать необходимые индексы в целях повышения произво- 
дительности. 


5.1. Система безопасности СУБД 


Система безопасности (Зесиу) предназначена для сохранности 
данных от злонамеренной порчи либо от несанкционированного доступа. 
Обычно система безопасности включает две составляющие: 

1. Разграничение доступа пользователей. 
2. Аудит действий пользователя. 

Кратко рассмотрим функции и реализацию каждой из составляю- 
щих. Системы безопасности различных СУБД существенно отличаются 
друг от друга (что вполне естественно), а стандарт в этой части является 
достаточно гибким и позволяет строить индивидуальные решения на ос- 
нове типовых конструкций. 

В дальнейшем изложении мы будем опираться на систему безопас- 
ности Ога е, понимая, что при переходе на любую новую СУБД придется 
потратить определенное время на освоение ее системы безопасности. 


5.1.1. Разграничение доступа пользователей 
Создание учетных записей пользователей 


Все СУБД предоставляют доступ к информации базы данных только 
зарегистрированным пользователям, имеющим учетные записи этой базы. 
При установке Отас!е автоматически создается несколько учетных запи- 
сей — это пользователи с именами 5У$ и ЗУЗТЕМ, обладающие всеми 
правами АБД (самыми обширными правами обладает 5Ү$, который име- 
ет право останавливать и запускать сервер), а также несколько пользова- 
телей, созданных в демонстрационных целях. 
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Для создания учетной записи каждого нового пользователя требует- 
ся создать стандартный объект ОЅЕВ с обязательным указанием пароля 
данного пользователя (пароли в словаре данных Огабе хранятся в зашиф- 
рованном виде, поэтому если пользователь забыл пароль, его нельзя по- 
смотреть, но можно сменить). В Отасе команда СКЕАТЕ ОЅЕВ ... со- 
держит еще ряд дополнительных параметров: 

СВЕАТЕ ОЕК имя пользователя 

ТШЕМТТЕТГЕО ВУ пароль 

[РЕЕАОГТ ТАВГЕЗРАСЕ имя табличного пространства] 
[ТЕМРОКАКҮ ТАВГЕЗРАСЕ 

имя _ временного табличного пространства] 

[ОООТА ОМШМІТЕР / размер предоставляемого дискового про- 
странства] 

[РКОЕП Е имя профиля] 


Например: 
СВЕАТЕ ОЅЕКБ и5ег1 
ТШЕМТГЕТЕО ВУ спецуп 
РЕРАОГТ ТАВГЕЅРАСЕ ОЅЕКЅ 
ТЕМРОКАВҮ ТАВІГЕЅРАСЕ ТЕМР 


В данной команде используются стандартные имена табличных про- 
странств, которые создаются при установке сервера ОгасІе. Табличное 
пространство – это файл (или несколько файлов, логически восприни- 
маемые Огасе как единое пространство для хранения таблиц или индек- 
сов). В приведенном примере размер части табличного пространства, 
предоставляемого пользователю, не ограничен (точнее, ограничен только 
размерами пространства). Специальный профиль для пользователя не 
создается. 

Несколько слов о профилях пользователей (подробные сведения вы- 
ходят за рамки курса). Создание индивидуальных профилей для пользо- 
вателей базы данных позволяет: 

1. Вести индивидуальную политику паролей (время жизни пароля) 

2. Ограничить ресурсы (количество одновременно открытых сес- 
сий, процессорное время, отводимое данному пользователю, или 
время для некоторого конкретного запроса, время ожидания от- 
вета сервера и ряд других важных ресурсов). 


Профиль создается при помощи команды 


СВЕАТЕ РКОЕП Е имя профиля [параметры профиля] 
и в любой момент может быть изменен командой 
АГТЕВ РВОЕШЕ ..... 
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Изменение учетной записи 


Команда АГТЕВ ОЅЕК имя ......позволяет изменять различные па- 
раметры учетной записи (кроме имени пользователя). 
Например: 
АГТЕК ОЗЕВ пег1 
ІЕМТІНЕР ВУ новый пароль 
Так можно сменить пароль пользователя. 
АГТЕВ ОЗЕВ изег1 ОООТА 100М ОМ 0ОЅЕК5 


Теперь для пользователя изет! размер его части табличного про- 
странства ОЗЕК$ ограничен 100 Мегабайтами. 


Удаление учетной записи 


С помощью команды ОВОР ОЅЕК... можно совсем удалить пользо- 

вателя из базы данных. Например, команда: 

ОБВОР ОЕК џѕег1 

удалит пользователя и5е11, но только в том случае, если он еще не создал 
ни одного объекта. 

Для того, чтобы гарантированно удалить любого пользователя, тре- 
буется применить эту команду с параметром САЗСАПЕ, с помощью ко- 
торого перед удалением пользователя удаляются все объекты в его схеме. 
ОБВОР 0$ЕК џѕег1 САЅСАРЕ 


Пользователи и схемы 

При создании учетной записи в Огас!е каждый пользователь одно- 
временно получает в распоряжение свою собственную схему в базе дан- 
ных с тем же именем, т.е одновременно неявно выполняется команда 
СВЕАТЕ ЅСНЕМА имя пользователя 

Напомним, что понятие схемы поддерживается стандартом. Это са- 
мостоятельная часть базы данных, все имена объектов, создаваемых 
пользователем, должны быть уникальны только в пределах схемы, по- 
скольку имя объекта (таблицы, представления и т.д.) в пределах всей базы 
данных складывается из двух составляющих: 
имя схемы.имя объекта 

Однако, получив в распоряжение собственную учетную запись и 
собственную схему базы данных, только что созданный пользователь не 
может даже подключиться к базе данных, не говоря уже о создании объ- 
ектов. Для выполнения любого действия в базе данных пользователю 
требуются права на выполнение подобных действий. Для этих целей вво- 
дятся два понятия — привилегии и роли. 
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5.1.2. Привилегии и роли 


Привилегии позволяют использовать определенные команды языка 
ЗОГ, по отношению к определенным ее объектам и предоставляются с 
помощью команды СКАМТ... Например, если пользователь и5ег1 владеет 
таблицей ѕѓџйепіѕ и выполняет команду 
СВАМТ ЅЕГЕСТ ОМ ѕоаепѕ ТО РИВЫС 
все пользователи (РОВШС) смогут выполнять команду ЗЕГЕСТ по отно- 
шению к таблице ѕіџйепіѕ, используя для этого составное имя и5- 
ег1. бет или короткий синоним, если он будет создан при помощи ко- 
манды: 

СВЕАТЕ РОВИС ЅҮМОМҮМ 5$@4еп6 РОБ оиѕег1 .Ѕиаепіѕ 

Из этого примера очевидно, что для нормальной работы большинст- 
ву пользователей необходимо предоставить очень большое количество 
привилегий. 

Упрощают работу с привилегиями роли – именованные группы при- 
вилегий, которые можно предоставлять пользователям с помощью той же 
команды СКАМТ, что и отдельные привилегии. В приложениях с боль- 
шим числом пользователей применение ролей намного уменьшает коли- 
чество команд ОКАМТ. Можно создать заранее определенный набор ро- 
лей, с помощью которых пользователям предоставляются только те при- 
вилегии, которые им необходимы. 

Роль – это стандартный объект базы данных, поэтому она создается 
при помощи стандартной команды СКЕАТЕ... 

СКЕАТЕ КОІЕ имя роли 

Например, создадим роль ѕіойепі, которую могут получить все поль- 
зователи-студенты, изучающие курс «Базы данных». 

СВЕАТЕ ВОГЕ зе 

Точно так же, как и только что созданный пользователь, новая роль 
еще не содержит никаких привилегий, поэтому присваивать эту роль 
пользователям бессмысленно. 

Наполнить роль набором конкретных привилегий в Огасіе можно 
при помощи уже упоминавшейся команды СКАМТ. Теперь уже можно 
представить эту команду в общем виде: 

СКАМТ список _привилегий/ролей ТО 
список _пользователей/ролей/РОВГЛС 

Отменить привилегию или роль, которые присвоены командой 
СКАМТ, можно с помощью другой команды: 

ВЕУОКЕ список привилегий/ролей ЕКОМ спи- 
сок_пользователей/ролей/РОВЕЛС 

Как видим, команды СКАМТ и ВЕУОКЕ являются универсальными, 
а сама система присвоения и отмены привилегий — очень гибкой. Новой 
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роли можно присвоить как конкретные привилегии, так и другие роли. 
Например, команда: 
ОКАМТ соппесі, геѕошсе ТО зе 
присвоит роли ѕіџйепі две стандартные роли, которые имеются во всех 
версиях Ога е — роль соппесі позволяет подключаться к базе данных, а 
роль геѕошсе позволяет создавать некоторые объекты в своей схеме (таб- 
лицы, индексы, представления, хранимый код). Если в целях успешного 
обучения пользователя с ролью $а4еп ему необходимо предоставить все 
права администратора, это можно сделать при помощи команды: 
СКАМТ аба ТО задет 

Такую роль уже не стыдно присвоить успешному студенту, допус- 
тим, ранее созданному при помощи команды СВЕАТЕ ОЅЕК џиѕег1 .. 
СКАМТ задепЕ ТО п5ег1 

Однако в реально функционирующих информационных системах 
использование стандартных ролей Огасе часто нежелательно, поскольку 
некоторые пользователи могут получить избыточные привилегии, при 
этом не получить какие-то нужные им специфические права. Поэтому 
проанализируем множество существующих привилегий, чтобы понять 
логику их присвоения пользователям и ролям. 

Как известно, основными составными частями языка ЗОГ, являются 
БОГ, и ОМГ. В соответствии с этим выделяют две больших группы при- 
вилегий — системные и объектные. 


Системные привилегии 


Системные привилегии получают администраторы БД и, частично, 
разработчики приложений. Если разработчикам приложений дается в 
распоряжение собственная тестовая база данных, они получают на нее 
любые системные привилегии, которые им необходимы в процессе разра- 
ботки и тестирования приложений. 

Системные привилегии — это права на выполнение команд СКЕАТЕ, 
АГТЕК ОКОР применительно к различным объектам базы данных в сво- 
ей (или любой) схеме. Если пользователи или роли наделяются привиле- 
гией на выполнение ОПГ, в любой схеме, к имени объекта добавляется 
клюсевое слово АМУ. Например: 

СКАМТ СВЕАТЕ ТАВГЕ ТО задет 

позволит включить в роль студент право создавать таблицы в своей схе- 
ме, а 

СВАМТ СВЕАТЕ АМҮ ТАВІЕ ТО адепт \УТТН СВАМТ ОРТІОМ 
право создавать таблицы в любой схеме, при этом роль ѕіџйем сможет 
передать эту привилегию другим пользователям или ролям. 

Важно отметить, что пользователь, создавший таблицу (неважно где 
— в своей или чужой схеме), автоматически становится ее владельцем 
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(отупег), при этом он автоматически получает все права объектного уров- 
ня на эту таблицу. Другими словами, владельцу таблицы не надо предос- 
тавлять отдельные права на манипулирование данными этой таблицы, но 
всем остальным пользователям такие права предоставлять нужно. 

Аналогично можно присвоить привилегии на любые другие команды 
ОРГ. Особо требуется отметить привилегию СКЕАТЕ ЗЕЗЗ1ОМ, которую 
должны получить все пользователи без исключения, поскольку это право 
на открытие сеанса связи с сервером Огасе (дословно — создание сессии). 

Привилегия АТЕВ ЗЕ ОМ, скорее всего, не потребуется рядовым 
пользователям, поскольку предоставляет право изменять важные систем- 
ные параметры в своем сеансе связи, которые могут повлиять, например, 
на производительность системы. 

В качестве примера создадим системную роль ассоипі сгеаќог, с по- 
мощью которой можно только создавать пользователей, а другие коман- 
ды уровня ОВА выполнять нельзя: 

СВЕАТЕ ВОГЕ ассои стеаюг 
СКАМТ СВЕАТЕ ЗЕ$ ТОМ, СВЕАТЕ ОЅЕК, АГТЕВ ОЅЕК 
ТО ассошпі стеаюг 

С помощью первой команды создается роль с именем 
ассоииЕ стеаюг. Вторая команда предоставляет этой роли возможность 
регистрации в базе данных, а также создания и изменения учетных запи- 
сей. 


Объектные привилегии 


Объектные привилегии позволяют пользователям выполнять кон- 
кретные действия на конкретном объекте. Такова, например, привилегия 
удалять строки в указанной таблице. Объектные привилегии назначаются 
конечным пользователям, так что они могут использовать приложения 
базы данных для выполнения конкретных задач. 

Объектные привилегии выдаются при помощи уже известной универ- 
сальной команды СКАМТ... 
СКАМТ список_объектных_привилегий 
ОМ имя таблицы/представления/процедуры 
ТО список _ролей/список_ пользователей /РОВИС 
[МІТН СКАМТ ОРТТОМ] 

В ОВАСГЕ существуют следующие привилегии объектного уровня: 

® ЅЕЕСТ позволяет другому пользователю выполнить запрос на вы- 
борку к данным указанной таблицы или представления. 

е  ПУУЕКТ позволяет вставлять строки в таблицу (возможно, используя 
для этих целей обновляемое представление) с помощью команды 
ІҸЅЕВТ. 
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е  ОРРАТЕ позволяет обновлять строки в таблице (обновляемом пред- 
ставлении) вне зависимости от того, были ли эти строки созданы 
этим пользователем или нет. 

» "РЕ ЕТЕ позволяет удалять из таблицы любые существующие стро- 
ки. С использованием представления можно ограничить то, какие 
строки будут удалены. 

»® ЕХЕСОТЕ даёт возможность пользователю, владеющему хранимым 
кодом базы данных (процедурами, функциями или пакетами), позво- 
лить другому пользователю ОКАСГЕ вызывать его процедурные 
объекты. 

е  АГТЕК даёт возможность пользователю ОКАСІЕ изменить опреде- 
ление заданной таблицы или последовательности. Не следует путать 
с системной привилегией АІТЕК ТАВГЕ, которая дает возможность 
изменять структуру любой таблицы в своей схеме. 

е  ПМЛОЕХ позволяет пользователю создавать индексы на указанную 
таблицу, владельцем которой он не является. Владелец эту привиле- 
гию имеет по умолчанию. 

В конце оператора СВАМТ привилегии объектного уровня может 
быть определена фраза МІТН СКАМТ ОРТІОМ, которая позволяет поль- 
зователю, получившему эту привилегию, передать её другому пользова- 
телю ОКАСГЕ. 

Например, пусть ранее был создан пользователь иѕег2. Предоставим 
ему только некоторые права пользователя нашей демонстрационной базы 
данных: 

СКАМТ СКЕАТЕ $Е5510М ТО пег2 

СВАМТ ЅЕГЕСТ, ІЧЅЕВТ ОМ тагкѕ ТО иѕег2 

СКАМТ ЅЕГЕСТ ОМ ѕќџйепіѕ ТО иѕег2 

СКАМТ ЕХЕСОТЕ ОМ сһапре рћопе ТО изег2 


5.1.3. Аудит действий пользователей 


Разграничение прав доступа пользователей вовсе не отменяет необ- 
ходимость контроля (аудита) их действий в базе данных. Ранее мы рас- 
смотрели, как организовать аудит некоторых действий при помощи триг- 
геров. 

Однако ОгасІе предоставляет дополнительнительную возможность 
всестороннего аудита всех операций, происходящих в базе данных, - ко- 
манду АОПТТ. Информация аудита записывается либо в специальную 
таблицу в схеме $ҮЅ (3У5.АЧО$), либо (в зависимости от применяемой 
системы) в журнал аудита операционной системы. 

Разрешается проводить аудит операций трех разных типов: 
® попыток регистрации в базе данных (аудит подключений), 
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® обращения к определенным объектам (аудит объектов), 
® определенных операций с базой данных (аудит действий). 

Во время аудита база данных по умолчанию должна регистрировать 
как успешные, так и неуспешные команды. Этот режим можно изменить 
при установке аудита любого типа. 


Аудит подключений 


Можно осуществлять аудит всех попыток соединения с базой дан- 
ных. Аудит попыток регистрации задается командой 
АОПТ ЕТОМ 
Чтобы производить аудит только тех попыток регистрации, которые за- 
вершаются или успешно или неуспешно, воспользуйтесь одной из сле- 
дующих команд: 

АОПТТ ЗЕ$ ОМ \УНЕМЕУЕК ЗОССЕ$ЗЕОГ 
АОПТТ ЗЕ$ ОМ \УНЕМЕУЕК МОТ ЗОССЕЗЗЕОГ, 

Если записи аудита хранятся в таблице $ҮЅ.АОРЮ$, их можно про- 
смотреть через представление словаря данных ОВА_АОПТ 8Е85103 
этой таблицы. 

Для запрещения аудита сеанса применяется команда МОАПРТТ 
МОАППТ ЗЕ ЗТОМ 


Аудит операций 


Любая команда рр, оказывающая воздействие на некоторый объ- 
ект базы данных, например на таблицу, представление или индекс, может 
быть подвергнута аудиту. При этом нетрудно сгруппировать операции 
СКВЕАТЕ, АІТЕВ и ОКОР, воздействующие на объекты. Группирование 
команд снижает объем административной работы, необходимой для уста- 
новки и поддержки параметров аудита. 

Так, для аудита всех команд, воздействующих на роли, нужно ввести 
команду 
АОПТ ВОГЕ 

Чтобы отменить заданную установку, следует ввести 
МОАОПТ ВОГЕ 

Существуют группы аудита ЗОГ-команд. Каждую группу можно 
применять для аудита всех 5ОГ-команд, входящих в нее. Например, с 
помощью команды АООТ КОГЕ, приведенной выше, будет осуществ- 
ляться аудит команд СКЕАТЕ ВОГЕ, АГТЕК КОГЕ и ОВОР ВОІЕ. 

Также можно осуществлять отдельный аудит для каждой команды, 
указанной операторным параметром. ОКАСІЕ предлагает следующие 
группы операторных параметров: 
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СОММЕСТ аудит всех случаев регистрации в ОКАСГЕ и отсоедине- 


ния от ОВАСІЕ 

РВА аудит команд, для выполнения которых необходимы пол- 
номочия администратора базы данных 

КЕ- аудит операций создания и удаления таблиц, кластеров, 

ЅООВСЕ представлений, индексов, табличных областей, типов и 
СИНОНИМОВ 

АШ. аудит всех этих команд 


Аудит объектов 


Помимо системных операций, выполняемых над объектами, аудиту 
можно подвергать операции ЗЕГЕСТ, ІЧЅЕВТ, ОРР”РАТЕ и РЕ ЕТЕ, вы- 
полняемые над конкретными таблицами. 

Конструкция, добавляемая для аудита объектов, - ВУ ЗЕЗЗОМ (на 
сеанс) или ВУ АССЕЗ$ (по доступу). Она определяет, нужно ли вносить 
запись аудита однажды для каждого сеанса или каждый раз при обраще- 
нии к объекту. Например, если пользователь выполнил над одной и той 
же таблицей четыре различных оператора ОР”РАТЕ, результатом аудита 
по доступу будет внесение четырех записей аудита — по одной на каждое 
обращение к таблице. Однако если в той же самой ситуации применить 
конструкцию ВУ ЗЕ$ЗТОМ, то будет внесена только одна запись аудита. 

Поэтому аудит по доступу может намного увеличить частоту внесе- 
ния записей аудита. Он используется достаточно редко и, как правило, 
для измерения числа отдельных операций, выполняемых в течение опре- 
деленного временного интервала; после завершения тестирования следует 
установить для аудита состояние ВУ ЗЕЗЗОМ. 

Ниже рассмотрены примеры использования рассмотренных спосо- 
бов аудита. В первой команде производится аудит всех команд ІЧЅЕВТ, 
выполняемых над таблицей ѕіџйепіѕ, находящейся в схеме џиѕег1. Во вто- 
рой команде аудиту подвергается каждая команда, воздействующая на 
таблицу тагкѕ. В третьей команде осуществляется аудит операций ОЕ- 
ГЕТЕ, выполняемых над таблицей 516] ес в течение сеанса: 

АПТ ПУЗЕКТ ОМ оиѕе1.ѕ(0йепіѕ 
АОРІТ АШ, ОМ џѕегІ.тагкѕ 
АОРІТ ОЕГЕТЕ ОМ иѕег1.ѕибјесіѕ ВУ $Е5510М№ 


142 


5.2. Поддержка транзакций 


Транзакция — единица работы СУБД, которая может быть выполнена 
либо целиком, либо вообще не выполнена. Объем транзакции может 
варьироваться от одного ЗОГ.-оператора до всех действий с базой данных, 
выполняемых приложением. Чтобы понять суть механизма транзакций, 
рассмотрим основные свойства, характеризующие транзакцию. 


5.2.1. Свойства транзакции 


Транзакция характеризуется четырьмя основными свойствами, часто 
называемыми свойствами АСИД – Атомарность, Согласованность, Изо- 
лированность, Долговечность. На английском языке эта аббревиатура 
также обозначается АСШ - Аюписйу, Сопя$епсу, [50]айоп, ига цу. 
Поясним каждое из свойств по отдельности. 


Атомарность 

Транзакция является неделимой, она выполняется полностью или не 
выполняется вообще; если транзакция прерывается на середине, то база 
данных должна остаться в том состоянии, которое она имела до начала 
транзакции. 


Согласованность (целостность) 

Транзакция переводит базу данных из одного согласованного (цело- 
стного) состояния в другое, также целостное. В ходе выполнения тран- 
закции база данных может временно пребывать в нецелостном состоянии. 

Очень многие правила целостности базы данных таковы, что их про- 
сто невозможно не нарушить, выполнив только одну команду ЗОГ. Такие 
команды объединяют в единую транзакцию, результатом которой являет- 
ся новое целостное состояние БД. В крайнем случае, если транзакция не 
сумеет довести БД до конечного целостного состояния, она вернется к 
начальному, также целостному, состоянию. 

Поясним это свойство на примере. Рассмотрим процесс удаления 
студента из нашей демонстрационной базы данных с перенесением дан- 
ных о студенте и всех его оценках в архивную базу данных. В предыду- 
щей лекции были рассмотрены триггеры для выполнения переноса в ар- 
хив всех строк таблицы оценок тагК$, относящихся к данному студенту, и 
строки с данными о самом студенте. Схематически процесс удаления 
строки из таблицы $4еп5 со всеми сопутствующими действиями пока- 
зан на рис.5.1. 
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Исходное состояние 


Оценки перенесены в архив. Данные о студенте пока в 
основной таблице 


Данные о студенте и в основной таблице, ив 
архиве.Оценки перенесены в архив 


Оценки перенесены в архив. Данные о студенте 
перенесены в архив. Процесс удаления завершен. 


фиксация 
Рис. 5.1. Процесс удаления строки из таблицы ѕїіийепіѕ 


Он состоит из четырех команд ЗОГ, выполняемых последовательно, 
причем все промежуточные состояния базы данных после выполнения 
отдельных команд являются несогласованными. При возникновении лю- 
бой внештатной ситуации (допустим, пользователь не имеет привилегий 
на выполнение какой-либо одной из операций или на архивные таблицы 
наложены какие-либо дополнительные ограничения) будет автоматиче- 
ски выполнен откат в исходное состояние. 

Наконец, после выполнения последнего удаления система снова 
окажется в согласованном состоянии. Но и в этот момент еще возможен 
откат в исходное состояние, на этот раз по команде КОГГВАСК, кото- 
рая уже инициируется пользователем, а не сервером. Откат станет не- 
возможным только после выполнения команды фиксации транзакции 
СОММІТ. Любая из этих двух команд, тем или иным образом, но за- 
вершает транзакцию. 
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Изоляция 

До сих пор мы не рассматривали особенности работы СУБД в мно- 
гопользовательской среде. Но в реальных информационных системах на 
основе сервера Огасе могут одновременно работать десятки тысяч поль- 
зователей, каждый из которых выполняет свои собственные транзакции. 
Свойство изоляции обозначает, что все транзакции выполняются изоли- 
рованно друг от друга. 

Несмотря на то, что в каждый момент времени сервер может выпол- 
нять параллельно несколько транзакций, общий результат их совместной 
работы гарантировнно будет таким же, каким он был бы при их последо- 
вательном выполнении; одновременно выполняющиеся транзакции не 
наложатся и не исказят результаты друг друга. 

Такой режим работы сервера называется сериальным и является ре- 
жимом по умолчанию для сервера Огасе. 


Долговременность 

После того как транзакция завершена и зафиксирована, результат ее 
выполнения гарантированно сохраняется в базе данных. При любых ава- 
рийных ситуациях, используя возможности сервера, можно восстановить 
все зафиксированные транзакции. Восстановление незафиксированных 
транзакций сервер, разумеется, не гарантирует. 


5.2.2. Поддержка транзакций в языке $01 


Для обеспечения всех перечисленных выше свойств транзакции не- 
обходима как языковая поддержка процессов инициализации и заверше- 
ния транзакции, так и механизмы их реализации сервером. Рассмотрим 
данные вопросы по порядку. 

Языковые правила поддержки транзакций для различных СУБД не- 
сколько различаются. Например, в Місгоѕоћ ЗОГ, Ѕегуег поддерживается 
команда начала транзакции ВЕСТМ ТКАМ[АСТІОМ]. В Огасіе такой ко- 
манды нет, но существуют четкие правила, регламентирующие моменты 
начала и завершения транзакции: 

1. Любая команда РОГ, выполняется как отдельная транзакция. 
Иными словами, поступлснис на сервер команды ООГ автоматичсски 
фиксирует результаты предыдущих команд ОМІ этого сеанса (если тако- 
вые были) и начинает новую транзакцию, а при завершении команды 
РОГ, автоматически фиксируются ее результаты. Таким образом, одна 
команда ООГ, вызывает те же действия, что и последовательность команд: 
СОММТ 
команда РОГ, 

СОММТ 
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Получается, что несколько команд ОПТ, нельзя объединить в единую 
транзакцию и откатить команду РОГ, при помощи стандартной команды 
КОГТВАСК в Огасіс также нельзя. 

2. Результаты выполнения команд РМГ, автоматически фиксируются 
только при включенном режиме АОТОСОММІТ (например, в настройках 
утилиты 5ОГ.*Р!а$ есть возможность включения этого режима). По умол- 
чанию этот режим отключен. Таким образом, все идущие подряд коман- 
ды ОМІ. воспринимаются как одна транзакция. 

Инициализация транзакции (неявная команда ВЕСПМ ТКАМЗАС- 
ТІОМ) происходит в следующих случаях: 
® первая команда в сеансе связи 
® первая команда после команд СОММІТ или КОГГВАСК 
® первая команда после команды РОГ, 


Завершение транзакции происходит при поступлении команд 
СОММІТ (завершение транзакции с фиксацией изменений) или КОГТ-- 
ВАСК (завершение транзакции с откатом изменений). Можно неявно 
зафиксировать команду транзакции из последовательности команд РМЕ 
любой следующей за ней командой РОГ. 

Стандарт 801. и многие СУБД, в том числе Огабе, предусматрива- 
ют так называемые точки сохранения. Точка сохранения задается опера- 
тором 
ЗАУЕРОТМТ имя точки сохранения 
и в операторе ВОТТВАСК имеется возможность отката транзакции не к 
началу, а к указанной точке сохранения: 

КОШВАСК ТО имя точки сохранения 

Данная команда выполняет откат только тех изменений, которые 

были сделаны после точки сохранения, и не завершает транзакцию. 


5.2.3. Механизмы СУБД для поддержки транзакций 


Поддержка транзакций требует значительных ресурсов и существен- 
но (во много раз!) замедляет производительность сервера. Однако в со- 
временных условиях допустить потерю или порчу информации в базе 
данных абсолютно недопустимо, поэтому правила АСИД реализуются 
всеми СУБД. Несмотря на особенности конкретных реализаций, имеется 
ряд универсальных механизмов поддержки транзакций. 

Мы рассмотрим эти обшие механизмы, добавив немного конкретных 
сведений по их воплощению в Отас[е. 
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Журнализация транзакций 
Ведение журналов транзакций преследует одновременно две цели: 
1) возможность отката транзакции; 
2) восстановление БД в случае аварийных ситуаций или сбоев. 


Сервер ведёт 2 вида журналов транзакций: 
Опао-журналы: 
используются для отката и ведутся для каждой транзакции отдельно. Как 
только очередная транзакция зафиксирована или откачена, то информа- 
ция из соответствующего Опдо-журнала удаляется. 

В Огасіе такие журналы иначе называются сегментами отката, они 
располагаются в отдельном табличном пространстве и содержат полную 
информацию о каждой транзакции, достаточную для ее успешного отка- 
та. Рекомендуемое количество Оп4о журналов в базе данных, которые 
должны быть в наличии, равно 1/2 (где п – количество одновременно ра- 
ботающих пользователей). 


Вейо-журнал: 

необходим для повторного выполнения транзакций при восстановлении 
данных. Это единый системный журнал, в который записываются резуль- 
таты всех зафиксированных транзакций. 

В аварийной ситуации, приведшей к порче данных, они восстанав- 
ливаются по резервной копии. Но резервная копия была снята в какой-то 
момент времени в прошлом. Все транзакции, которые прошли в системе 
после снятия последней резервной копии, восстанавливаются по Кедо- 
журналу. 

Такой механизм полностью гарантирует выполнение правила Долго- 
вечность из аббревиатуры АСИД. Для того чтобы гарантировать возмож- 
ность безусловного восстановления всех зафиксированных транзакций, 
принято правило упреждающей записи в журнал транзакций – по команде 
СОММІТ результаты транзакции сначала заносятся в Кейо-журнал, а по- 
том (возможно не сразу), записываются в табличное пространство. 

Кратко рассмотрим, как организовано ведение системного журнала 
транзакций в Отасе. С учетом огромного количества информации, кото- 
рая постоянно записывается в этот журнал в процессе нормальной работы 
информационной системы, он состоит из двух частей — оперативной и 
архивной. Оперативная часть, в свою очередь, содержит два журнала (для 
повышения надежности каждый из журналов обычно ведется в двух эк- 
земплярах). В каждый момент времени один из журналов заполняется 
информацией о транзакциях сервера, а другой в это время копируется в 
архивный журнал, который организован на отдельном носителе большого 
объема. Этот процесс схематически показан на рис. 5.2. 
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Сервер Огасе 


Архив 


Рис. 5.2. Заполнение журнала транзакций в Оғасіе 


Сериальный график исполнения транзакций. Монитор 
транзакций 


Для обеспечения свойства изолированности транзакций при макси- 
мально возможной в этих условиях производительности сервера исполь- 
зуется механизм сериализации транзакций. Сериальный график исполне- 
ния транзакций обеспечивает параллельное исполнение сервером не- 
скольких транзакций (т.е. команды различных транзакции могут испол- 
няться на сервере «вперемешку»), но результат работы гарантированно 
должен быть точно таким же, как если бы эти транзакции исполнялись 
последовательно. 

Составлением графика выполнения транзакций, пришедших на сер- 
вер, занимается специальный компонент СУБД, который называется мо- 
нитором транзакций. Это очень сложный программный модуль, выпол- 
няющий задачу оптимизации суммарного времени исполнения транзак- 
ций с учетом блокировок ресурсов в процессе одновременного обраще- 
ния к ним нескольких транзакций. 

Механизмы блокировки ресурсов рассмотрим отдельно. 
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Механизмы блокировки 


Большинство СУБД позволяют любому числу транзакций одновре- 
менно осуществлять доступ к одной и той же базе данных и в них суще- 
ствуют механизмы управления параллельными процессами, предотвра- 
щающие нежелательные воздействия одних транзакций на другие. По 
сути, это механизм блокирования, главная идея которого достаточно про- 
ста. Если транзакции нужны гарантии, что некоторый объект (база дан- 
ных, таблица, или строка), в котором она заинтересована, не будет изме- 
нен каким-либо непредсказуемым образом в течение требуемого проме- 
жутка времени, она устанавливает блокировку этого объекта. Результат 
блокировки заключается в том, чтобы изолировать этот объект от других 
транзакций и предотвратить его изменение средствами этих транзакций. 

Рассмотрим кратко, как организованы блокировки в Огасіе. 

Во-первых, объектом блокирования может быть вся таблица или от- 
дельная строка, поэтому различают блокировки типа Т (Та Ме) или В 
(Коҳ). Объектом блокирования в исключительных случаях может быть и 
вся база данных, но при обычной многопользовательской работе этого не 
допускают. 

Во-вторых, поддерживается не только полная блокировка ресурса 
(эксклюзивная блокировка — обозначается как Х-блокировка), но и разде- 
ляемая (ЗВагед) блокировка (обозначается как $-блокировка). Разделяемая 
блокировка позволяет нескольким транзакциям одновременно использо- 
вать ресурс, но пока не снята разделяемая блокировка, сервер не может 
наложить на этот ресурс эксклюзивную блокировку. 

Теперь разберем конкретно, какую блокировку накладывает сервер 
на ресурсы при исполнении определенных команд ЗОГ. 

Команды СВЕАТЕ/АГТЕВ/ОКОР ТАВГЕ накладывают эксклюзив- 
ную блокировку на уровне таблицы (блокировка ТХ). Это значит, что 
нельзя выполнять никаких действий над таблицей, пока не будет закон- 
чена соответствующая операция ООГ.. Очевидно, для команд ОПТ, и фик- 
сация выполняет автоматически с целью быстрее освободить таблицу от 
эксклюзивной блокироки. 

Команды ПУЗЕВТ/ОЕГЕТЕ/ОРРАТЕ используют ресурсы в более 
мягком режиме. Каждая из этих команд накладывает эксклюзивную бло- 
кировку только на ту строку, которую она в данный момент обрабатывает 
(блокировка КХ). Однако одновременно накладывается эксклюзивная 
блокировка на всю таблицу (блокировка Т5), и это означает, что никакая 
БОГ, операция не может быть выполнена над таблицей до тех пор, пока 
не закончатся все ОМІ -операции над этой таблицей и не будет снята по- 
следняя ТЅ-блокировка (при нормальной работе такое случится, скорее 
всего, только к концу рабочего дня или в обеденный перерыв). 
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Команда ЗЕГЕСТ не накладывает никакой блокировки на те таблицы, 
данные из которых она выбирает. Сервер Ога е гарантирует каждой ко- 
манде выборки неизменность данных таблиц в процессе ее выполнения. 
Если в процессе выполнения какой-нибудь объемной и протяженной по 
времени выборки успела зафиксироваться какая-либо транзакция обновле- 
ния данных, команда выборки не увидит результаты этой транзакции. 


5.3. Настройка производительности. Индексы 


Управление большими и сверхбольшими базами данных, проектиро- 
вание и разработка приложений для них имеет свои особенности. Поэто- 
му, чтобы не допустить ухудшения характеристик как отдельных прило- 
жений, так и всей системы в целом, требуется использование специаль- 
ных методов, повышающих скорость доступа к данным. 

Как правило, используется комплексный подход. Под этим понима- 
ется оптимизация всех звеньев системы — серверной, клиентской и сете- 
вой части. Существует целый ряд способов настройки производительно- 
сти: настройка рабочих станций клиентов, сетевого транспорта, оптими- 
зация клиентских приложений, оптимизация серверного РГ./ЗОГ-кода и 
ЅОГ -запросов. В данной лекции мы подробно рассмотрим основной спо- 
соб повышения производительности при исполнении ЗОГ.-запросов – ис- 
пользование индексов. 


5.3.1. Понятие индекса 


Прежде чем рассматривать различные способы организации индек- 
сов, следует ввести понятие селективности столбца. 

Селективность (5@йесй»”Йу) столбца — это процент строк, имеющих 
одинаковое значение для индексированного столбца. Селективность 
столбца высокая, если в нем мало одинаковых значений. Автоматически 
создаются индексы для первичных ключей или столбцов, для которых 
существует ограничение на уникальность значений. Эти индексы наибо- 
лее эффективны. Столбцы с малым количеством уникальных значений 
имеют низкую селективность, большинство распространенных способов 
организации индексов при поиске по столбцам с низкой селективностью 
не обеспечивают существенного ускорения. 

Наряду с селективностью столбца при решении вопроса о целесооб- 
разности индексирования по тому или иному столбцу требуется учиты- 
вать динамику обновления данных в этом столбце (и вообще в таблице). 
Дело в том, что в процессе изменения данных столбца приходится вно- 
сить изменения не только в таблицу, но и в индекс на основе данного 
столбца, что замедляет операции обновления данных. 
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Таким образом, целесообразно создавать индексы для столбцов с 
высокой селективностью, для которых чаще выполняются операции по- 
иска данных, чем их обновления. 

Нужно отметить важный факт — если в запросах на выборку логи- 
ческое условие накладывается не на значение столбца, а на результат не- 
которой функции от него, то индекс, созданный для столбца, не исполь- 
зуется. 

Индексы бывают двух видов — простые и составные. Составной ин- 
декс — это индекс, включающий более чем один столбец. Можно совме- 
стно проиндексировать два или более столбца, каждый из которых обла- 
дает низкой селективностью, а пара их значений — высокой. Если все 
столбцы, используемые запросом, входят в составной индекс, то обраще- 
ния к таблицам можно вовсе избежать — все данные будут считаны толь- 
ко из индекса. Для эффективного использования составного индекса не- 
обходимо, чтобы логические условия были наложены на ведущие столб- 
цы индекса, то есть на те столбцы, которые были указаны первыми при 
создании индекса. 

Как правило, в индексах хранятся значения индексируемых 
столбцов таблицы и физические адреса строк для каждого из храни- 
мых значений столбца (столбцов). В Ога е у каждой строки таблицы 
есть собственный уникальный идентификатор КОЙ’О, который пол- 
ностью определяет ее физический адрес на диске. Чтобы найти строку 
в таблице по заданному значению столбца, необходимо найти соответ- 
ствующие КОЙ7 в индексе и затем сразу перейти к указанным ими 
строкам в таблице. 

Как уже упоминалось, индексы являются вспомогательным объек- 
том, поэтому они не поддерживаются стандартом $01. Тем не менее, все 
СУБД используют индексы и больших принципиальных различий в по- 
литике использования индексов не наблюдается. 

На сегодняшний день создание и поддержка индексов в большинстве 
случаев является обязанностью администратора базы данных. Если раз- 
работчик имеет привилегию создания индексов, он самостоятельно может 
создавать индексы в целях ускорения своих поисковых запросов. Чтобы 
принимать взвешенное решение о создании тех или иных индексов, нуж- 
но хорошо знать, какие именно способы организации индексов поддер- 
живает конкретная СУБД. 

Далее мы остановимся на основных способах индексирования, при- 
нятых в Отас[е. 
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5.3.2. Обзор индексов Огасіе 


В Огас имеется несколько типов индексов: 
® древовидные индексы (В-деревья). 
® хешированные индексы (йа5й). 
® индексы на основе битовых карт или битовые индексы (Рійлар). 

В-деревья были реализованы в Огасе практически с самого начала 
се существования, затем появились хешированные индексы, а затем - би- 
товые карты. 

Понимание того, когда и где следует использовать конкретные типы 
индексов, очень важно для эффективного их применения. В-деревья ис- 
пользуются наиболее часто, в то время как хешированные и битовые ин- 
дексы лишь при наличии некоторых условий могут обеспечить сущест- 
венные преимущества в выполнении определенных запросов. 

Оператор создания индекса использует следующий синтаксис: 
СКЕАТЕ [ОМТООЕ| ВТТМАР] ІҸ”Ех имя индекса 
ОМ имя таблицы ( имя столбца , [...]) 

Для удаления индекса используется команда 
ОКОР ІХРЕх <ИМЯР> (удалить) 

Можно перестроить существующий индекс без его удаления и по- 
вторного создания при помощи команды: 

АТТЕК ТҸЮЕХ<ИМЯ> КВЕВОПЛ (перестроить индекс) 
АГТЕВ ІҸрЕХ<ИМЯ> ОМОЗАВГЕ (отключить индекс на время, 
чтобы снова включить обратно при помощи КЕВОП.О) 

Далее рассматривается, как работают индексы, а также приводятся 
рекомендации, в каких случаях и почему их следует использовать. 


В-деревья 

Видимо, наиболее популярным подходом к организации индексов в 
базах данных является использование техники В-деревьев. В-дерево со- 
держит по одному индексному элементу для каждой строки таблицы, в 
которой имеется непустое (МОТ МОГГ.) индексное значение. С точки зре- 
ния внешнего логического представления, В-дерево - это сбалансирован- 
ное сильно ветвистое дерево во внешней памяти (рис.5.3). 


Рис. 5.3. Древовидный индекс по текстовому столбцу 
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С точки зрения физической организации, В-дерево представляется 
как мультисписочная структура страниц внешней памяти, т.е. каждому 
узлу дерева соответствует блок внешней памяти (страница). Внутренние 
и листовые страницы обычно имеют разную структуру. 

В типовом случае структура внутренней страницы выглядит сле- 
дующим образом: 


М1 ключ) М2 ключ) М3 .... Ми ключи) Мп+1) ключи+1) 


При этом выдерживаются следующие свойства: 
ключ(1) <= ключ(2) <=... <= ключ(п); 
в странице дерева Мп находятся ключи К со значениями ключ(т) <= К <= 
ключ(т+1). 

Листовая страница обычно содержит значение индекса и идентифи- 
каторы строк (КОМІР”) и имеет следующую структуру: 


ключ) сп) ключ?) сп(2) .... ключ сп) 


Листовая страница обладает следующими свойствами: 

е ключ(1) < ключ(2) <... < ключ(0; 

е сп(т) - упорядоченный список идентификаторов кортежей (№), 
включающих значение ключ(т); 

® листовые страницы связаны одно- или двунаправленным спи- 
ском. 

Поиск в В-дереве - это прохождение от корня к листу в соответствии 
с заданным значением ключа. Заметим, что поскольку деревья сильно 
ветвистые и сбалансированные, то для выполнения поиска по любому 
значению ключа потребуется одно и то же (и обычно небольшое) число 
обменов с внешней памятью. Более точно, в сбалансированном дереве, 
где длины всех путей от корня к листу одни и те же, если во внутренней 
странице помещается п ключей, то при хранении т записей требуется 
дерево глубиной Іов. (т). Если п достаточно велико (обычный случай), то 
глубина дерева невелика, и производится быстрый поиск. 

Основной "изюминкой" В-деревьев является автоматическое под- 
держание свойства сбалансированности. Рассмотрим, как это делается 
при выполнении операций занесения и удаления записей. 

При занесении новой записи выполняется: 

• Поиск листовой страницы. Фактически, производится обычный по- 
иск по ключу. Если в В-дереве не содержится ключ с заданным зна- 


153 


чением, то будет получен номер страницы, в которой ему надлежит 
содержаться, и соответствующие координаты внутри страницы. 
Помещение записи на место. Естественно, что вся работа произ- 
водится в буферах оперативной памяти. Листовая страница, в ко- 
торую требуется занести запись, считывается в буфер, и в нем 
выполняется операция вставки. Размер буфера должен превы- 
шать размер страницы внешней памяти. 

Если после выполнения вставки новой записи размер используе- 
мой части буфера не превосходит размера страницы, то на этом 
выполнение операции занесения записи заканчивается. Буфер 
может быть немедленно вытолкнут во внешнюю память или вре- 
менно сохранен в оперативной памяти в зависимости от полити- 
ки управления буферами. 

Если же возникло переполнение буфера (т.е. размер его исполь- 
зуемой части превосходит размер страницы), то выполняется 
расщепление страницы. Для этого запрашивается новая страница 
внешней памяти, используемая часть буфера разбивается, грубо 
говоря, пополам (так, чтобы вторая половина также начиналась с 
ключа), и вторая половина записывается во вновь выделенную 
страницу, а в старой странице модифицируется значение размера 
свободной памяти. Естественно, модифицируются ссылки по 
списку листовых страниц. 

Чтобы обеспечить доступ от корня дерева к заново заведенной 
странице, необходимо соответствующим образом модифициро- 
вать внутреннюю страницу, являющуюся предком ранее сущест- 
вовавшей листовой страницы, т.е. вставить в нее соответствую- 
щее значение ключа и ссылку на новую страницу. При выполне- 
нии этого действия может снова произойти переполнение теперь 
уже внутренней страницы, и она будет расщеплена на две. В ре- 
зультате потребуется вставить значение ключа и ссылку на но- 
вую страницу во внутреннюю страницу-предка выше по иерар- 
ХИИ И Т.Д. 

Предельным случаем является переполнение корневой страницы 
В-дерева. В этом случае она тоже расщепляется на две, и заво- 
дится новая корневая страница дерева, т.е. его глубина увеличи- 
вается на единицу. 


При удалении записи выполняются следующие действия: 


Поиск записи по ключу. Если запись не найдена, то удалять ни- 
чего не нужно. 

Реальное удаление записи в буфере, в который прочитана соот- 
ветствующая листовая страница. 
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® Если после выполнения этой подоперации размер занятой в бу- 
фере области оказывается таковым, что его сумма с размером за- 
нятой области в листовых страницах, являющихся левым или 
правым братом данной страницы, больше, чем размер страницы, 
операция завершается. 

® Иначе производится слияние с правым или левым братом, т.е. в 
буфере производится новый образ страницы, содержащей общую 
информацию из данной страницы и ее левого или правого брата. 
Ставшая ненужной листовая страница заносится в список сво- 
бодных страниц. Соответствующим образом корректируется спи- 
сок листовых страниц. 

® Чтобы устранить возможность доступа от корня к освобожден- 
ной странице, нужно удалить соответствующее значение ключа и 
ссылку на освобожденную страницу из внутренней страницы - ее 
предка. При этом может возникнуть потребность в слиянии этой 
страницы с ее левым или правыми братьями ит.д. 

® Предельным случаем является полное опустошение корневой 
страницы дерева, которое возможно после слияния последних 
двух потомков корня. В этом случае корневая страница освобож- 
дается, а глубина дерева уменьшается на единицу. 

Как видно, при выполнении операций вставки и удаления свойство 
сбалансированности В-дерева сохраняется, а внешняя память расходуется 
достаточно экономно. 

Проблемой является то, что при выполнении операций модификации 
слишком часто могут возникать расщепления и слияния. Чтобы добиться 
эффективного использования внешней памяти с минимизацией числа рас- 
щеплений и слияний, применяются более сложные приемы, в том числе: 

® упреждающие расщепления, т.е. расщепления страницы не при ее 
переполнении, а несколько раньше, когда степень заполненности 
страницы достигает некоторого уровня; 

• переливания, т.е. поддержание равновесного заполнения сосед- 
них страниц; 

е слияния 3-в-2, т.е. порождение двух листовых страниц на основе 
содержимого трех соседних. 

Следует заметить, что при организации мультидоступа к В-деревьям, 
характерного при их использовании в СУБД, приходится решать ряд не- 
тривиальных проблем. Конечно, грубые решения очевидны, например 
монопольный захват В-дерева на все выполнение операции модификации. 
Но существуют и более тонкие решения. 

Сбалансированное дерево автоматически не уравновешивает рас- 
пределение ключей в пределах дерева так, чтобы половина ключей нахо- 
дилась бы на одной стороне В-дерева, а другая половина — на другой. 
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Очевидно, что нет необходимости перестраивать дерево всякий раз, когда 
добавляются или удаляются ключи. Однако если ключи добавляются или 
удаляются только на одной стороне дерева, то распределение индексных 
ключей может стать неравномерным, с изрядным числом разреженных и 
даже опустошенных блоков по одну сторону дерева. В этом случае ин- 
декс рекомендуется перестроить. 

На В-деревьях для извлечения данных по запросу может использо- 
ваться механизм быстрого полного просмотра (јаѕі ўи! ѕсап). Этот меха- 
низм дает существенные преимущества, если все запрошенные из кон- 
кретной таблицы данные могут быть получены только из индекса. При 
быстром полном просмотре эффективный многоблочный ввод/вывод, 
обычно применяемый для полных просмотров таблиц, используется для 
прочтения всех листовых блоков В-дерева. Поскольку число листовых 
блоков индекса, скорее всего, намного меньше, чем блоков данных в таб- 
лице, для выполнения запроса требуется просмотреть меньшее число 
блоков. Поэтому просмотр индекса совершится значительно быстрее, чем 
полный просмотр таблицы, хотя иногда неравномерное распределение 
ключей снижает эффективность быстрого полного просмотра, поскольку 
требуется просмотреть большее число листовых блоков (содержащих 
малое или вообще нулевое число элементов). При этом следует учитывать 
наличие или отсутствие в таблице пустых значений, которые, как было 
сказано выше, в индекс не заносятся. 

В-деревья можно использовать для поиска данных, как по условиям 
равенства, так и по условиям неравенства. Это единственный тип индек- 
сов, который можно использовать для предикатов неравенства: ИКЕ, 
ВЕТҸЕЕМ, “>”, “>=”, “<”, “<=”. Исключение представляет случай ис- 
пользования предиката МКЕ при сравнении с шаблоном вида ‘%выра- 
жение” или ‘ выражение’. В-деревья хранят только непустые значения 
ключей, так что можно построить разреженное В-дерево. 


Хешированные индексы 

Хешированные индексы реализованы в Огасе в виде хешированных 
кластеров. Хешированный кластер — специализированный вид организа- 
ции данных, обеспечивающий быстрый доступ к строкам таблицы. При 
обращении к хешированному кластеру по значению кластерного ключа 
применяется функция хеширования (ћаѕћіпе), результатом которой явля- 
ется значение хешированного ключа и адрес блока данных. Хеширован- 
ный кластер группирует в одном блоке строки, содержащие одинаковые 
значения этой функции от ключей. На любой таблице можно построить 
только один хешированный индекс. 

Доступ к таблице посредством В-дерева требует выполнения, по 
меньшей мере, двух операций ввода/вывода, а обычно больше (если таб- 
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лица, а потому и дерево ее индекса, большая). Доступ к хешированному 
кластеру потребует один вызов функции хеширования и одну операцию 
ввода/вывода для кластера. 

Хешированные кластеры целесообразно использовать для больших 
таблиц, поиск по которым, как правило, осуществляется с условиями ра- 
венства по ключевому столбцу (столбцам). При этом значения ключей не 
модифицируются. Поэтому заранее можно точно определять число зна- 
чений хешированных ключей и размер кластера. В дополнение к этому, 
ключевой столбец (столбцы) должен быть высокоселективен. 

Главным преимуществом хешированного индекса по сравнению с В- 
деревом является лучшая производительность выборки, вставки, обнов- 
ления и удаления записей, если используются условия равенства для всех 
ключевых столбцов кластера. 


Битовые индексы 

Битовые индексы обеспечивают быстрое обращение к данным 
больших таблиц, когда доступ организуется по столбцам с низкой или 
средней селективностью с использованием различных сочетаний условий 
равенства. Битовый индекс построен в виде двоичной карты (рітар) по 
значениям ключа. Это означает, что для каждой строки таблицы в двоич- 
ной карте, то есть в определенном бите некоторой последовательности 
байтов, поставлена 1 или 0 (“да” или “нет”) в соответствии со значением 
ключа конкретной строки. Во время обработки запросов оптимизатор 
ОгасІе может динамически преобразовывать элементы индексов битовой 
карты в идентификаторы строк. 

Пример организации битового индекса по низкоселективному 
столбцу «пол» показан в таблицах. 


Таблица В тар индекс по столбцу «пол» 
Вож Ш ФИО пол Воу Ш М Ж 

1 Попов М 1 1 0 

2 Иванова Ж 2 0 1 

3 Сидорова Ж 3 0 1 


Битовые карты нецелесообразно применять для часто обновляемых 
столбцов, поскольку даже простое изменение одной строки обычно при- 
водит к копированию всей соответствующей секции битовой карты. В 
приведенном примере столбец «пол» вообще не обновляется, так что если 
данные из таблицы удаляются редко, можно использовать данный индекс 
без снижения производительности. 

Еще необходимо учесть, что Отас!е сжимает хранимые битовые кар- 
ты. В результате для индекса битовой карты может потребоваться диско- 
вое пространство, составляющее 5-10% пространства, необходимого для 
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обычного индекса. Таким образом, можно применять индексы на основе 
битовых карт по отношению к любому низкоселективному столбцу, часто 
используемому в конструкции МНЕВЕ, при условии, что набор значений 
этого столбца ограничен. Битовые индексы можно использовать для по- 
иска только по условиям равенства (“=”, П“). Если необходим доступ по 
интервалу индексированных значений, то предпочтительнее использовать 
В-деревья. 


Индекс-таблицы 

Индекс-таблица — это таблица, которая физически построена в виде 
двоичного дерева относительно своего первичного ключа. Начиная с 
Огас1е8, существует возможность определить таблицу, которая одновре- 
менно является и собственным индексом, что устраняет ведение двух от- 
дельных структур. Как правило, это таблицы с короткими строками, об- 
ращение к которым всегда производится или по первичному ключу, или 
полным сканированием. Данные в таких таблицах отсортированы по зна- 
чениям столбца первичного ключа и сохраняются так, как если бы вся 
таблица целиком содержалась в одном индексе. 

Чтобы минимизировать объем работы, необходимой для активного 
управления индексами, следует использовать индекс-таблицу лишь в тех 
случаях, когда данные очень статичны. Не рекомендуется использовать 
индекс-таблицы, если строки имеют относительно большую длину, на- 
пример, свыше 20% от размера блока. В этом случае лучшим выбором 
является использование обычных таблиц и индексов. 

Для создания индекс-таблиц в команде СКЕАТЕ ТАВІЕ указывают- 
ся ключевые слова ОКСАМУАТІОМ ПХПЕХ. 

Пример создания индексно-организованной таблицы: 

СВЕАТЕ ТАВГЕ Табшаех 

(АП МОМВЕК(4) РЕТМАКУ КЕУ, 

А2 УАВСНАВ(40) 

) 

ОКСАМ!/АТТОМ ПХОЕХ; 

Существуют некоторые ограничения при работе с индекс-таблицами. 
Наиболее важно, что их строки не имеют идентификаторов (КОМІР), 
поэтому не могут быть созданы никакие дополнительные индексы, за ис- 
ключением обязательного первичного ключа. 

Следу ет отметить, что индекс-таблицы активно используются и в других 
СУБД, например, Місгоѕой ЗОГ, Зегуег по умолчанию создает именно 
такие таблицы. 
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Заключение 


К сожалению, ограниченный объем учебного пособия не позволил 
автору включить в него все аспекты технологий баз данных, которые мо- 
гут потребоваться специалисту в будущей деятельности. Однако, тех 
фундаментальных базовых знаний, которые можно получить при изуче- 
нии всех пяти глав пособия, вполне достаточно для дальнейшего самооб- 
разования с помошью многочисленных информационных ресурсов, кото- 
рые прекрасно дополнят полученные знания в области систем баз данных. 

Принимая во внимание высокую динамику развития технологий баз 
данных, можно считать данное пособие всего лишь стартовым учебным 
материалом, на основе которого будут формироваться новые знания на 
протяжении всей профессиональной карьеры выпускника технического 
вуза, работающего в сфере информационных технологий. 
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